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

DeflateStream.Length throws NotSupportedException #255

New Issue
Open
opened 2026-01-29 22:09:06 +00:00 by claunia · 3 comments
claunia commented 2026-01-29 22:09:06 +00:00
Owner
Copy Link

Originally created by @evil-shrike on GitHub (Oct 26, 2017).

Is it by design?

System.NotSupportedException: Specified method is not supported.
    at SharpCompress.Compressors.Deflate.DeflateStream.get_Length()

Why DeflateStream can't return its Length?

This DeflateStream is actually picked up from zipArchive.Entries by name:

  ZipArchiveEntry contentEntry = _zipArchive.Entries.FirstOrDefault(e => e.Key == itemName);
  if (contentEntry != null)
  {
    return contentEntry.OpenEntryStream();
  }

That contentEntry has Size property. But stream returned by OpenEntryStream (DeflateStream) throws on reading its Length property.
I can guess while it's happening (probably because ZipArchiveEntry.Size is extracted from metadata) but it's inconvenient. Because it means I can't return Stream in my API (not bound to the lib) - as it can throws.

I'd suggest to make that Stream make safe and not to throw in Length.

Originally created by @evil-shrike on GitHub (Oct 26, 2017). Is it by design? ``` System.NotSupportedException: Specified method is not supported. at SharpCompress.Compressors.Deflate.DeflateStream.get_Length() ``` Why DeflateStream can't return its Length? This DeflateStream is actually picked up from zipArchive.Entries by name: ``` ZipArchiveEntry contentEntry = _zipArchive.Entries.FirstOrDefault(e => e.Key == itemName); if (contentEntry != null) { return contentEntry.OpenEntryStream(); } ``` That `contentEntry` has Size property. But stream returned by `OpenEntryStream` (DeflateStream) throws on reading its `Length` property. I can guess while it's happening (probably because ZipArchiveEntry.Size is extracted from metadata) but it's inconvenient. Because it means I can't return Stream in my API (not bound to the lib) - as it can throws. I'd suggest to make that Stream make safe and not to throw in `Length`.
claunia commented 2026-01-29 22:09:06 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Oct 26, 2017):

That is by design. Most streams aren't seekable in this API so you can't just do Stream.Length. This is because very large archives or archives based on network streams are a primary use-case.

@adamhathcock commented on GitHub (Oct 26, 2017): That is by design. Most streams aren't seekable in this API so you can't just do Stream.Length. This is because very large archives or archives based on network streams are a primary use-case.
claunia commented 2026-01-29 22:09:06 +00:00
Author
Owner
Copy Link

@evil-shrike commented on GitHub (Oct 26, 2017):

Ok, in general it makes sense (one should check CanSeek before calling Stream.Length), but in this case Size is known...

@evil-shrike commented on GitHub (Oct 26, 2017): Ok, in general it makes sense (one should check CanSeek before calling `Stream.Length`), but in this case Size is known...
claunia commented 2026-01-29 22:09:07 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Oct 26, 2017):

The size isn't always known. The source of the data could be a stream that isn't seekable. Sometimes, size isn't known on a zip archive if it was created in a streaming manner.

There could be work done to know the stream size in some cases but I haven't put the work in to do that. Just don't do Stream.Length. Why do you need that?

@adamhathcock commented on GitHub (Oct 26, 2017): The size isn't always known. The source of the data could be a stream that isn't seekable. Sometimes, size isn't known on a zip archive if it was created in a streaming manner. There could be work done to know the stream size in some cases but I haven't put the work in to do that. Just don't do Stream.Length. Why do you need that?
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#255
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?