starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-03 21:23:38 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

Failed validation when using Zip64 with System.IO.Packaging #720

New Issue
Open
opened 2026-01-29 22:16:24 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 22:16:24 +00:00
Owner
Copy Link

Originally created by @a-carvallo on GitHub (Nov 18, 2025).

Originally assigned to: @Copilot on GitHub.

Hi there, ran into this little problem when using SharpCompress.

A zip archive created with UseZip64 set to true will fail to open using ZipPackage (from System.IO.Packaging) with .NET Framework 4.8.

The exception occurs in ZipIOLocalFileBlock.Validate() here:

if (VersionNeededToExtract != centralDirFileHeader.VersionNeededToExtract || GeneralPurposeBitFlag != centralDirFileHeader.GeneralPurposeBitFlag || CompressedSize != centralDirFileHeader.CompressedSize || UncompressedSize != centralDirFileHeader.UncompressedSize || CompressionMethod != centralDirFileHeader.CompressionMethod || Crc32 != centralDirFileHeader.Crc32)
{
	throw new FileFormatException(SR.Get("CorruptedData"));
}

VersionNeededToExtract value is 45 while centralDirFileHeader.VersionNeededToExtract is 20.
This mismatch seems to come from the fact that in SharpCompress the Local File Header will always have its version set to 45 when UseZip64 is true, but the version in the Central Directory File Header will be 45 only if size/offset is over uint.MaxValue (which makes sense).

Not sure what's the best way to handle this, an easy one would probably be to set both versions to 45 as soon as the flag is true ? (but this may not be optimal/trivial).

In SharpCompress these parts seem to be in ZipWriter.WriteToStream() / ZipWriter.WriteHeader() for the LFH and in ZipCentralDirectoryEntry.Write() for the CDFH.

Small code to reproduce the issue:

using System.IO.Packaging;

using SharpCompress.Archives;
using SharpCompress.Archives.Zip;
using SharpCompress.Common;
using SharpCompress.Writers;
using SharpCompress.Writers.Zip;

WriterOptions writerOptions = new ZipWriterOptions(CompressionType.Deflate)
{
    LeaveStreamOpen = false,
    UseZip64 = true
};
string file = "test_zip64.zip";

ZipArchive zipArchive = ZipArchive.Create();
zipArchive.AddEntry("empty", new MemoryStream());
zipArchive.SaveTo(file, writerOptions);

using var package = ZipPackage.Open(file, FileMode.Open, FileAccess.Read);

Kind of related to #164

Originally created by @a-carvallo on GitHub (Nov 18, 2025). Originally assigned to: @Copilot on GitHub. Hi there, ran into this little problem when using SharpCompress. A zip archive created with `UseZip64` set to `true` will fail to open using `ZipPackage` (from `System.IO.Packaging`) with .NET Framework 4.8. The exception occurs in `ZipIOLocalFileBlock.Validate()` here: ```cs if (VersionNeededToExtract != centralDirFileHeader.VersionNeededToExtract || GeneralPurposeBitFlag != centralDirFileHeader.GeneralPurposeBitFlag || CompressedSize != centralDirFileHeader.CompressedSize || UncompressedSize != centralDirFileHeader.UncompressedSize || CompressionMethod != centralDirFileHeader.CompressionMethod || Crc32 != centralDirFileHeader.Crc32) { throw new FileFormatException(SR.Get("CorruptedData")); } ``` `VersionNeededToExtract` value is `45` while `centralDirFileHeader.VersionNeededToExtract` is `20`. This mismatch seems to come from the fact that in SharpCompress the Local File Header will always have its version set to `45` when `UseZip64` is `true`, but the version in the Central Directory File Header will be `45` only if size/offset is over `uint.MaxValue` (which makes sense). Not sure what's the best way to handle this, an easy one would probably be to set both versions to `45` as soon as the flag is `true` ? (but this may not be optimal/trivial). In SharpCompress these parts seem to be in `ZipWriter.WriteToStream()` / `ZipWriter.WriteHeader()` for the LFH and in `ZipCentralDirectoryEntry.Write()` for the CDFH. Small code to reproduce the issue: ```cs using System.IO.Packaging; using SharpCompress.Archives; using SharpCompress.Archives.Zip; using SharpCompress.Common; using SharpCompress.Writers; using SharpCompress.Writers.Zip; WriterOptions writerOptions = new ZipWriterOptions(CompressionType.Deflate) { LeaveStreamOpen = false, UseZip64 = true }; string file = "test_zip64.zip"; ZipArchive zipArchive = ZipArchive.Create(); zipArchive.AddEntry("empty", new MemoryStream()); zipArchive.SaveTo(file, writerOptions); using var package = ZipPackage.Open(file, FileMode.Open, FileAccess.Read); ``` Kind of related to #164
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#720
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?