mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-08 05:27:04 +00:00
ZIP ReaderFactory IEntry properties are not assigned #580
Reference in New Issue
Block a user
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?
Originally created by @jbrockerville on GitHub (Jul 31, 2023).
I have ZIP files created with a unknown app. I am accessing the
IEntryentries via theReaderFactory(a la USAGE.md). The entries contain their key, but all the other properties (e.g., CRC, uncompressed size, compressed size, various date-times, etc.) are not assigned (set to zero or null).A couple interesting observations:
IEntryproperties, opening the entry stream and copying it works fine.ArchiveFactoryto access these ZIP files, theirIEntryproperties are assigned.ReaderFactorythen works fine.Unfortunately, I am not at liberty to share the offending archives. Instead, I have attached the output from Info-Zip from an original and repacked file. I hope some information can be gleaned from them. If I had to guess, I would say it is a problem with the zip headers.
archive.zip.txt
archive-repack.zip.txt
@Erior commented on GitHub (Sep 4, 2023):
The archive is probably written in a Stream mode, that is when you don't know that size of the file being added.
CRC and sizes would then be 0, date time etc might or might not be set.
And it comforms with your statements above and also the dump you generated with Info-Zip
Check the test file Zip.none.datadescriptors.zip
You can use zipdetails command if it is available to you, it should show the "Local Header" information.
@adamhathcock commented on GitHub (Sep 7, 2023):
To echo what @Erior it saying: if the zips were made with Streaming mode, the File Headers have missing data. There should be Flie Trailers that have sizes and CRC.
These can't be known ahead of time with Reader because the file sizes, etc are unknown with Reader mode and Streaming zips
@jbrockerville commented on GitHub (Sep 7, 2023):
Huh... I was unaware that you could do that. I guess I just learned something. I can accept that explanation. Thanks for looking into it and replying. I've made a solution to handle when we encounter an archive like this. But it's nice to know it's a feature, not a bug. ;)
Maybe add some words somewhere describing this possibility?
@adamhathcock commented on GitHub (Sep 8, 2023):
It's not really a feature, just a known short coming of Reader (Streaming mode) and Streaming made zip files.
How do you suggest describing it? People always want more docs but I haven't found a good way to for this project as well as in my day job :)