-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
DotNet 7 Regression when reading large Zip files #77159
Comments
Tagging subscribers to this area: @dotnet/area-system-io-compression Issue DetailsDescriptionWhen trying to read After some research, I realized that very likely culprit is in runtime/src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs Lines 768 to 773 in 10fc8ae
I have verified using multiple tools like 7zip that the zip file is completely valid. I have also repeatedly reproed the issue by producing various >4GB zip files in various tools - all with the same result: entries that are beyond the 4GB offset are not readable and all return Reproduction StepsJust try calling Expected behaviorAs it was in DotNet 6 (which is the last version I used where it worked). Should be able to read entries in a zip archive beyond the 4 GB mark. Actual behaviorNone of the zip entries beyond the 4GB mark can be opened. Regression?Yes, tried it on RC1, but looks like it was introduced at least in Preview 5, possibly earlier. And by the looks of it present in RC2 since the affected files have not changed for RC2. Known WorkaroundsUse other library. (Not really a workaround though). Configuration
Other informationHopefully either @danmoseley or @adamsitnik can take a look ASAP. This is a serious regression that prevents a whole lot of valid scenarios!
|
It's not related, but I notice I had a typo in one of the original tests here. Should be uncompressed https://github.com/dotnet/runtime/pull/68106/files#diff-ea21d1af009443a658bc821a6eb47860f7887ff70155a68f11990ec64875a2dcR860 |
Thank you for looking into this and acting quickly. I noticed the PR is still not merged. Is there a chance it will nonetheless make it into RTM of DotNet 7? This is a serious blocking issue. |
It just got merged, we are going to backport it to 7.0: #77605. I am expecting that it will be included in the first servicing update in January (cc @jeffhandley) Once again thank you for trying our RC builds and reporting the issue! |
Minor correction: The first servicing update is in December. This backport will be considered in Tactics next Tuesday. |
Description
When trying to read
ZipArchiveEntry
s from an 8GB zip file that contains ~8K ~1MB files I start gettingA local file header is corrupt.
exception. This happens only once I get passed the "~4GB" mark (i.e. those entries that are located within first 4GB are all read just fine, but all the rest are all unreadable).After some research, I realized that very likely culprit is in
src/libraries/System.IO.Compression/src/System/IO/Compression/ZipBlocks.cs
, likely this PR (commit). I traced the issue by stepping through in VS to this place:runtime/src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs
Lines 768 to 773 in 10fc8ae
_offsetOfLocalHeader
is set to0xffffffff
and is being passed directly into the reader which tries to read the data, which is obviously wrong. Instead it should be using the offset from the Zip64 extended info.I have verified using multiple tools like 7zip that the zip file is completely valid. I have also repeatedly reproed the issue by producing various >4GB zip files in various tools - all with the same result: entries that are beyond the 4GB offset are not readable and all return
A local file header is corrupt.
exception.Reproduction Steps
Just try calling
ZipArchiveEntry.Open()
on an entry in a zip archive which is located beyond the 4GB mark (in the archive file).Expected behavior
As it was in DotNet 6 (which is the last version I used where it worked). Should be able to read entries in a zip archive beyond the 4 GB mark.
Actual behavior
None of the zip entries beyond the 4GB mark can be opened.
Regression?
Yes, tried it on RC1, but looks like it was introduced at least in Preview 5, possibly earlier. And by the looks of it present in RC2 since the affected files have not changed for RC2.
Known Workarounds
Use other library. (Not really a workaround though).
Configuration
Other information
Hopefully either @danmoseley or @adamsitnik can take a look ASAP. This is a serious regression that prevents a whole lot of valid scenarios!
The text was updated successfully, but these errors were encountered: