When entry data is provided as a strict ByteString, we don't need to
stream the data to determine its uncompressed size. Thus, we can rule
out the need for Zip64 extra fields early.
This addresses issue #126.
Previously the code did not account for the fact that the initial stub local
header (with uncompressed and compressed sizes set to 0) could not serve for
correct estimation of the final local header size due to the fact that the
local header size was determined by the uncompressed and compressed sizes of
the corresponding data, which are only known after streaming of the data.
These sizes dictated whether or not a zip64 extra field entry should be
included in the header or not. Thus, before this fix there would be cases of
corruption where the final (longer) local header written by seeking back to
the beginning of the initial stub local header after the data had been
streamed would overwrite the beginning of the data.
This is fixed by
* always writing a zip64 entry in local headers, which does not violate the
spec and will be safely ignored in the case of smaller entries, and
* respecting the spec more precisely where it says that whenever there is a
zip64 extra field entry in a local header both uncompressed and compressed
sizes must always be written.
This is deemed safe because the only source of size variation for local
headers is the uncompressed and compressed sizes of the corresponding data.
Set user permissions on linux platform as follows:
* if an existing file is added, use its permissions
* if an entry is generated from a bytestring or a stream, use 0600
This behavior mimics the zip utility.
It was very hard to set permissions using this library, as the permissions
were not properly documented. Here we try to solve the problem in 2 ways:
1. We add a low level documentation that explains how to work with
permissions.
2. We introduce unix specific helpers that allow to describe permissions in
a human readable way.
Unfortunately making those helpers OS agnostic is a pretty hard task we
enable them only on the Unix platforms.
The bzlib-conduit library is causing us trouble when trying to
cross-compile it for Windows.
The best thing to do in our case is to remove the dependency.
This change adds -fdisable-bzip2. Under this flag, if a caller
attempts to compress or decompress a BZip2 entry, then an exception
will be thrown.
Resolves#57
Now that the situation is clear, I think it's pretty safe to remove this
additional run of the test suite. It's unlikely that we will run into new
Zip64-related issues.
Close#14.
Two new features:
* Added explicit check of “version needed to extract”, so if archive
uses some advanced features that we do not support yet, parsing fails.
* Value of “version needed to extract” field is now calculated
dynamically with respect to actually used features, e.g. if you just
store or deflate a not very big file, ‘2.0’ version will be
written (previously we wrote ‘4.6’ unconditionally). This is needed to
avoid scaring tools that can only handle basic Zip archives.
MS DOS time/date format is quite limited in range of dates it can
represent. Here we ensure that all ‘UTCTime’ values we use for testing
are in appropriate range.
Quytelda Kahja
Niklas Hambüchen
Mark Karpov
Alexander Vershilov
Csaba Hruska
Rodney Lorrimar
Ramakrishnan Muthukrishnan
mrkkrp