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
Mark Karpov
Julian Ospald
Alexander Vershilov
Csaba Hruska
Moritz Kiefer
Rodney Lorrimar