Added Support for loading the 64bit libzip.dll on Windows. #10
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Windows Apps can be either 32 or 64 bit. This commit uses the SetDllDirectory function to add a new search path to the current search paths so the correct 64 bit dll can be loaded. In this case it adds an "x64" directory which is relative to where the LibZipSharp assembly is. https://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspx
grendello
added a commit
that referenced
this pull request
Jan 25, 2022
Context: dbe3236 dbe3236 fixed an issue of data corruption when deleting files from the archive by properly creating temporary streams when `libzip` requested data modifications. However, a bug crept in which causes the temporary stream to be rewound, instead of the destination one, when data is written back. This has the effect of overwriting the ZIP local file header structure with, essentially, random data and causes errors similar to: error XABBA7000: Xamarin.Tools.Zip.ZipException: Zip archive inconsistent: entry 0: invalid WinZip AES extra field Xamarin.Android.Common.targets(2289,2): error ANDZA0000: zip W 01-25 15:03:13 9516 56652 WARNING: header mismatch The issue can be seen by either attempting to unpack the archive: $ 7z x base.zip ERROR: Headers Error : dex/classes.dex ERROR: Headers Error : root/assemblies/assemblies.blob $ unzip base.zip file #9: bad zipfile offset (local header sig): 49783 file #10: bad zipfile offset (local header sig): 127988 Or by looking at the file with `zipinfo -vv base.zip`: Central directory entry #10: --------------------------- There are an extra 9 bytes preceding this file. root/assemblies/assemblies.blob offset of local header from start of archive: 127988 (000000000001F3F4h) bytes Not only the local header is thought to be at the incorrect offset, it also doesn't have the correct signature: # show valid header $ hexdump -n 4 -C base.zip 00000000 50 4b 03 04 |PK..| # show invalid header $ hexdump -s 127988 -n 4 -C base.zip 0001f3f4 49 be 37 16 |I.7.| $ hexdump -s $((127988 - 9)) -n 4 -C base.zip 0001f3eb 88 26 de 2c |.&.,| Attempt to fix the problem by rewinding the destination stream on write.
grendello
added a commit
that referenced
this pull request
Jan 25, 2022
Context: dbe3236 dbe3236 fixed an issue of data corruption when deleting files from the archive by properly creating temporary streams when `libzip` requested data modifications. However, a bug crept in which causes the temporary stream to be rewound, instead of the destination one, when data is written back. This has the effect of overwriting the ZIP local file header structure with, essentially, random data and causes errors similar to: error XABBA7000: Xamarin.Tools.Zip.ZipException: Zip archive inconsistent: entry 0: invalid WinZip AES extra field Xamarin.Android.Common.targets(2289,2): error ANDZA0000: zip W 01-25 15:03:13 9516 56652 WARNING: header mismatch The issue can be seen by either attempting to unpack the archive: $ 7z x base.zip ERROR: Headers Error : dex/classes.dex ERROR: Headers Error : root/assemblies/assemblies.blob $ unzip base.zip file #9: bad zipfile offset (local header sig): 49783 file #10: bad zipfile offset (local header sig): 127988 Or by looking at the file with `zipinfo -vv base.zip`: Central directory entry #10: --------------------------- There are an extra 9 bytes preceding this file. root/assemblies/assemblies.blob offset of local header from start of archive: 127988 (000000000001F3F4h) bytes Not only the local header is thought to be at the incorrect offset, it also doesn't have the correct signature: # show valid header $ hexdump -n 4 -C base.zip 00000000 50 4b 03 04 |PK..| # show invalid header $ hexdump -s 127988 -n 4 -C base.zip 0001f3f4 49 be 37 16 |I.7.| $ hexdump -s $((127988 - 9)) -n 4 -C base.zip 0001f3eb 88 26 de 2c |.&.,| Attempt to fix the problem by rewinding the destination stream on write. Fix found by Dean Ellis (@dellis1972)
grendello
added a commit
that referenced
this pull request
Jan 25, 2022
Context: dbe3236 dbe3236 fixed an issue of data corruption when deleting files from the archive by properly creating temporary streams when `libzip` requested data modifications. However, a bug crept in which causes the temporary stream to be rewound, instead of the destination one, when data is written back. This has the effect of overwriting the ZIP local file header structure with, essentially, random data and causes errors similar to: error XABBA7000: Xamarin.Tools.Zip.ZipException: Zip archive inconsistent: entry 0: invalid WinZip AES extra field Xamarin.Android.Common.targets(2289,2): error ANDZA0000: zip W 01-25 15:03:13 9516 56652 WARNING: header mismatch The issue can be seen by either attempting to unpack the archive: $ 7z x base.zip ERROR: Headers Error : dex/classes.dex ERROR: Headers Error : root/assemblies/assemblies.blob $ unzip base.zip file #9: bad zipfile offset (local header sig): 49783 file #10: bad zipfile offset (local header sig): 127988 Or by looking at the file with `zipinfo -vv base.zip`: Central directory entry #10: --------------------------- There are an extra 9 bytes preceding this file. root/assemblies/assemblies.blob offset of local header from start of archive: 127988 (000000000001F3F4h) bytes Not only the local header is thought to be at the incorrect offset, it also doesn't have the correct signature: # show valid header $ hexdump -n 4 -C base.zip 00000000 50 4b 03 04 |PK..| # show invalid header $ hexdump -s 127988 -n 4 -C base.zip 0001f3f4 49 be 37 16 |I.7.| $ hexdump -s $((127988 - 9)) -n 4 -C base.zip 0001f3eb 88 26 de 2c |.&.,| Attempt to fix the problem by rewinding the destination stream on write. Fix found by Dean Ellis (@dellis1972)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Windows Apps can be either 32 or 64 bit. This commit uses
the
function to add a new search path to the current search paths
so the correct 64 bit dll can be loaded. In this case it adds
an "x64" directory which is relative to where the LibZipSharp
assembly is.
https://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspx