[zip] Bugfix on zipfiles not having data descriptor after filedata. #11686
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.