Open sebbernery opened 3 weeks ago
Sorry, I'm not sure why the CI fails, but while trying to solve the issue I think I misunderstood the API of zip Reader class, I guess I have to call Reader.unzip() when a file entry is compressed. But the decompression is transparent if there is a data descriptor and require a call to unzip() if it's not here. I'll check to correct the CI failure (I guess I should set compressed to false to avoid that haxelib try to unzip an already decompressed data) but is this a behavior you want to keep ? I may miss some context.
Hello ! I had an issue with zipfiles generated with the tool 7zip on windows. Some files once extracted with haxe.zip.ZipReader was corrupted.
In the zip file format (here or here) some metadata (CRC32 and filesize) can be in the header of the file (in the local file header) or in the footer of the file (in the data descriptor after the compressed data). If the third bit of the local file header flags is 1, there is a data descriptor, not if the flag is 0. Haxe ZipReader don't decompress files if the third bit of flag is at 0 so the result data (supposed to be decompressed) is the compressed data. This patch fix this behaviour.
I attach two files if you want to test this issue. The first one works and the second is broken in the current version of Haxe. test_zip_roller.zip test_zip_7zip.zip
Here is a snippet to test the issue:
Output without patch:
With the patch
The archive contains a file uncompressed (test/salut.txt).
Have a nice day.