mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-08 13:34:57 +00:00
SharpCompress generates Zips that don't pass System.IO.Packaging validation #122
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @anaisbetts on GitHub (Aug 23, 2016).
I'm working on switching Squirrel.Windows to SharpCompress in https://github.com/Squirrel/Squirrel.Windows/pull/803, and one thing I'm seeing is that files compressed with SharpCompress and then later opened via NuGet's code (which uses WPF's System.IO.Packaging code) blow up here:
http://referencesource.microsoft.com/#WindowsBase/Base/MS/Internal/IO/Zip/ZipIOLocalFileBlock.cs,788
If you want a live repro, clone that PR and run the
CreateFullPackagesFromDeltaSmokeTesttest, or if you want a sample file to check out, https://cl.ly/0W3D3V1x0V2J@adamhathcock commented on GitHub (Aug 23, 2016):
Did you create the zip file with ZipWriter? It might not like the streaming mode entries as there's a trailing header behind the file bytes to record the actual size and whatnot.
Knowing which way you created the file will help the most. It could be a bug in SharpCompress or it could be that the packaging API doesn't like streaming created zip files that are to spec :) Does something like WinZip or WinRar open the file?
I'm about to go on vacation for a week so I'm not sure when I'll get to take a look.
@anaisbetts commented on GitHub (Aug 23, 2016):
Usually something like https://github.com/Squirrel/Squirrel.Windows/pull/803/files#diff-dc4101658eac6c569618cb80ac0bffccR99. 7-Zip seems to have no problem opening the file
@adamhathcock commented on GitHub (Aug 23, 2016):
Cool. I'll try to setup a test Tuesday when I'm back in front of a machine.
@adamhathcock commented on GitHub (Sep 27, 2016):
Coming up with nothing. Then again, I don't think I know how to properly use the Packaging API.
@anaisbetts commented on GitHub (Sep 27, 2016):
@adamhathcock You and me both fam. An easier test if you're playing around with it is to use the NuGet library, the
ZipPackageclass there is super straightforward and hits this bug@adamhathcock commented on GitHub (Sep 28, 2016):
@paulcbetts I must be thick because I just downloaded the Squirrel.Core.1.1.0.0.nupkg and can enumerate the parts
@anaisbetts commented on GitHub (Oct 21, 2016):
@adamhathcock Lemme try it again with the latest SharpCompress
@damieng commented on GitHub (May 19, 2017):
So I've found what is causing this - it's the check to make sure the version requirement from the Central Directory File Header matches the version requirement of the ZIP Local File Header contained within it.
Unfortunately for SharpCompress generated files there is a mismatch.
ZIP central directory file header is set to 10 at https://github.com/adamhathcock/sharpcompress/blob/master/src/SharpCompress/Writers/Zip/ZipCentralDirectoryEntry.cs#L33
ZIP local file header is set to 20 at https://github.com/adamhathcock/sharpcompress/blob/master/src/SharpCompress/Writers/Zip/ZipWriter.cs#L162
I suspect we can probably just change the 20 to a 10 in the ZipWriter? I can send a PR with the fix and a test if this is the case. Alternatively I guess we could change the central one to 20 but that might reduce compatibility. I guess a lot of tools outside of Microsoft's Packaging are only using one of the two.
@adamhathcock commented on GitHub (May 19, 2017):
That's definitely a problem.
Quickly reviewing APPNOTE.txt again I should be dynamically changing the version needed to extract based on features.
Changing to 10 is probably the benign thing to do for now. I'll investigate more by looking at other implementations next week.
@adamhathcock commented on GitHub (May 19, 2017):
Maybe it's just the fact that it's mismatched is the problem. Otherwise I would have said 20 is the proper thing for now.
@damieng commented on GitHub (May 19, 2017):
It looks like Deflate is only supported in version '20' so I think you're right - changing the ZIP central dictory file header to '20' would be the smallest fix.
If there was a need to support '10' then it would need to also not use deflate or encryption.