-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SharpCompress generates Zips that don't pass System.IO.Packaging validation #164
Comments
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. |
Usually something like https://github.com/Squirrel/Squirrel.Windows/pull/803/files#diff-dc4101658eac6c569618cb80ac0bffccR99. 7-Zip seems to have no problem opening the file |
Cool. I'll try to setup a test Tuesday when I'm back in front of a machine. |
Coming up with nothing. Then again, I don't think I know how to properly use the Packaging API. |
@adamhathcock You and me both fam. An easier test if you're playing around with it is to use the NuGet library, the |
@paulcbetts I must be thick because I just downloaded the Squirrel.Core.1.1.0.0.nupkg and can enumerate the parts
|
@adamhathcock Lemme try it again with the latest SharpCompress |
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. |
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. |
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. |
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. |
Default zip ver to 20 (deflate/encyption), fixes #164
I'm working on switching Squirrel.Windows to SharpCompress in Squirrel/Squirrel.Windows#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
CreateFullPackagesFromDeltaSmokeTest
test, or if you want a sample file to check out, https://cl.ly/0W3D3V1x0V2JThe text was updated successfully, but these errors were encountered: