Skip to content

[release/10.0] Fix ZIP64 header corruption when large file at large offset#124468

Open
github-actions[bot] wants to merge 4 commits intorelease/10.0from
backport/pr-122837-to-release/10.0
Open

[release/10.0] Fix ZIP64 header corruption when large file at large offset#124468
github-actions[bot] wants to merge 4 commits intorelease/10.0from
backport/pr-122837-to-release/10.0

Conversation

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Feb 16, 2026

Backport of #122837 to release/10.0
/cc @iremyux @copilot

Fixes #122489

Description

ZipArchive produces corrupted ZIP file when a 4GB+ file is written into archive which has already 4GB+ size.
This caused 7-Zip to show Extra_ERROR Zip64_ERROR and ZipFile.OpenRead to throw InvalidDataException: A local file header is corrupt on file produced by .NET.

Customer Impact

Reported by the RavenDB in #122489, whose snapshot backups produced with ZipArchive became unrecoverable due to ZIP header corruption.

Regression

Yes. The issue was introduced in .NET10 with commit 44c08b8

Testing

  • Added regression test LargeFile_At_LargeOffset_ZIP64_HeaderPreservation covering the specific scenario
  • Test includes OOM exception handling with `SkipTestException to gracefully skip when memory is insufficient
  • All existing System.IO.Compression tests pass

Risk

Low. Single-line logic change in a specific code path that only affects ZIP64 central directory header writing when both size and offset of entry exceed 4GB. We stop throwing away previously initialized Zip64ExtraField.

Copilot AI and others added 4 commits February 16, 2026 15:23
When both AreSizesTooLarge and IsOffsetTooLarge are true,
the Zip64ExtraField was being overwritten in the central
directory header logic, losing the size information.

This fixes the issue by reusing the existing Zip64ExtraField
when adding the offset, using ??= instead of creating a new object.

Fixes #114205

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
Wrap buffer allocation in try-catch for OutOfMemoryException
and throw SkipTestException to gracefully skip the test
when insufficient memory is available.

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
@dotnet-policy-service
Copy link
Contributor

Tagging subscribers to this area: @karelz, @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Copy link
Member

@rzikm rzikm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@karelz karelz added the Servicing-consider Issue for next servicing release review label Mar 6, 2026
@karelz karelz added this to the 10.0.x milestone Mar 6, 2026
@iremyux
Copy link
Contributor

iremyux commented Mar 11, 2026

The PR was approved via email - I'll go ahead and add the servicing-approved label.

@iremyux iremyux added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Mar 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants