When copying an entry from another archive, there is no reason to add
Zip64 extra fields if the source entry doesn't have them. This change
checks whether a copied entry had Zip64 extra fields before
appending/updating the field in the local header.
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.
This data constructor of ZipException is defined unconditionally and
replaces BZip2Unsupported and ZstdUnsupported which previously were defined
conditionally via CPP.
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.
As per zip spec we may want to encode host version. This version is used by
e.g. the unzip utility in order to understand how to interpret external
info (type of files and permissions).
Current algorithm is pretty naive, we do not test for all OS versions
supported by zip. Instead we check if we run on windows and put 0 in that
case (MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems). Otherwise we put 3
(UNIX).
This way code works properly on the unix OS, and we keep old behavior for
the other OS.
Note that we didn't change ‘toVersion’ function, as it already masked the
higher byte where OS information was stored.
This code was tested manually by storing archive and then unarchiving it via
unzip. There is no automated test because such test would require external
tools (unzip).
We have seen a bunch of errors on CI of the form
```
C:\users\foobar\ghcBDA1.zip: DeleteFile "\\\\?\\C:\\users\\foobar\\ghcBDA1.zip": does not exist (The system cannot find the file specified.)
```
I haven’t managed to reproduce this but looking at the code it seems
like we can be interrupted with an async exception (we kill threads
pretty aggressively) in the `bracketOnError` call after the file has
been renamed but before the whole block returns. In this case, the
file will not exist but you’ll run the cleanup in `bracketOnError`
anyway which will then fail.
We could try to fix this by masking things differently but ignoring
the error seems like a simpler and more robust solution.
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
Quytelda Kahja
Mark Karpov
Niklas Hambüchen
Patrick Chilton
Masahiro Sakai
dependabot[bot]
Julian Ospald
Alexander Vershilov
Csaba Hruska
Moritz Kiefer
Rodney Lorrimar
Ramakrishnan Muthukrishnan
mrkkrp
Alexey Karakulov
Rahul Muttineni