mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-07 21:22:04 +00:00
When UnZip, Entry.Size = 0 but in reality it's not so + Entry.Attrib value = "Entry.Attrib threw an exception of type 'System.NotImplementedException'" #691
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 @alexey-shilkin on GitHub (Jul 14, 2025).
I wrote C# code below, where SrcFullFileName = attached zip file:
using (Stream stream = File.OpenRead(SrcFullFileName)){
using (SharpCompress.Readers.IReader? reader = ReaderFactory.Open(stream)){
while (reader.MoveToNextEntry()) {
int i = reader.Entry.Size; /// = 0 - it is a bug + also Entry.Attrib value = "Entry.Attrib threw an exception of type 'System.NotImplementedException'"
}
}
}
Problem is that after reader.MoveToNextEntry() when Entry has been read - entry has size = 0, but actually it is not 0 + Entry.Attrib threw exception System.NotImplementedException (see screeenshot)
I use nuget SharpCompress 0.40.0 (same bug was in earlier versions as well) + .NET 9 + VS 17.14.8
bug - size of XML is 0 but its size is not 0.zip
@Morilli commented on GitHub (Jul 16, 2025):
The reader interface is not suited for what you're apparently trying to do. If you want accurate information about each entry in a zip file, you should use
ZipArchiveorArchiveFactory.Open. That's because there are two headers for each zip entry, one in front of the entry data and one at the very end of the file. In case of this zip, the local entry header does not contain accurate information about size or crc of the file data, so the reader can only provide this "incorrect" data.The file attributes are similarly only present in the directory header at the end of the and won't be visible to the reader. That said, file attributes for zip entries don't seem to be exposed in general so you won't get information even when using
ZipArchive. That could be fixed though.@alexey-shilkin commented on GitHub (Jul 20, 2025):
Thanks. Your advise helped.