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
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.
One is supposed to accumulate a builder with a right fold:
https://www.reddit.com/r/haskell/comments/35udfy/fixing_an_aeson_performance_bug_sometimes_the_old/cr94pdj
I skipped that with this attempt, which unfolds the text directly. It
seems 10 or more times as fast if I send /usr/share/dict/words through
it. ‘unfoldrN’ is a pretty strong function with text since it is
basically just replicates to the stream representation.
Alexander Vershilov
Csaba Hruska
Mark Karpov
Moritz Kiefer
Rodney Lorrimar
Ramakrishnan Muthukrishnan
mrkkrp
Alexey Karakulov
Rahul Muttineni
Christopher Wells
Michael Thompson