ZIP64 Streaming Extraction Failure #614

Open
opened 2026-01-29 22:14:41 +00:00 by claunia · 3 comments
Owner

Originally created by @pathartl on GitHub (Mar 7, 2024).

I've been able to pretty consistently replicate an issue extracting ZIP64's in a stream where it will extract all entries up until a >4GB file and then silently skip over every other entry.

I believe the issue may lie with how the header is read in StreamingZipHeaderFactory. From my limited testing it seems like it's trying to read the header for the next entry 16 bytes past the start of the actual header. This causes ZipHeaderFactory.ReadHeader to return null and stops reading more of the archive.

Originally created by @pathartl on GitHub (Mar 7, 2024). I've been able to pretty consistently replicate an issue extracting ZIP64's in a stream where it will extract all entries up until a >4GB file and then silently skip over every other entry. I believe the issue may lie with how the header is read in StreamingZipHeaderFactory. From my limited testing it seems like it's trying to read the header for the next entry 16 bytes past the start of the actual header. This causes ZipHeaderFactory.ReadHeader to return null and stops reading more of the archive.
claunia added the bugup for grabs labels 2026-01-29 22:14:41 +00:00
Author
Owner

@adamhathcock commented on GitHub (Mar 7, 2024):

Definitely seems like a bug in the ZIP64 byte reading. Back to reading the spec. Maybe a bug in Reader vs Archive

@adamhathcock commented on GitHub (Mar 7, 2024): Definitely seems like a bug in the ZIP64 byte reading. Back to reading the spec. Maybe a bug in Reader vs Archive
Author
Owner

@Erior commented on GitHub (Jun 9, 2024):

Do we have a test file or test file generator for this one?

@Erior commented on GitHub (Jun 9, 2024): Do we have a test file or test file generator for this one?
Author
Owner

@pathartl commented on GitHub (Jun 22, 2024):

Might have fixed in PR #852

Haven't looked into why tests are failing. I was able to create a test archive by zipping a couple of small files, then a large >4GB file, and then another couple of small files. Might need to be in alphabetical order to replicate the original issue correctly. The extraction would skip any files after the first ZIP64 file is extracted because of the improper handling of the header data.

@pathartl commented on GitHub (Jun 22, 2024): Might have fixed in PR #852 Haven't looked into why tests are failing. I was able to create a test archive by zipping a couple of small files, then a large >4GB file, and then another couple of small files. Might need to be in alphabetical order to replicate the original issue correctly. The extraction would skip any files after the first ZIP64 file is extracted because of the improper handling of the header data.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#614