Allow Getting of Position of Stream #44

Open
opened 2026-01-29 22:04:26 +00:00 by claunia · 2 comments
Owner

Originally created by @thegreatco on GitHub (Jul 20, 2015).

Retrieval of the position of either the current stream (eg, number of bytes already read) or the underlying compressed stream would be helpful when trying to determine read rates for display.

I am fine with just getting the current position of the underlying stream and not the number of inflated bytes, but I suspect both are equally easy to expose.

Originally created by @thegreatco on GitHub (Jul 20, 2015). Retrieval of the position of either the current stream (eg, number of bytes already read) or the underlying compressed stream would be helpful when trying to determine read rates for display. I am fine with just getting the current position of the underlying stream and not the number of inflated bytes, but I suspect both are equally easy to expose.
Author
Owner

@adamhathcock commented on GitHub (Jul 20, 2015):

A lot of streams are forward-only and don't have a position (e.g. network stream). If you want to have to display something, you could count it yourself.

A lot of this library was with decompressing on the fly from gigabyte files or network streams where random seeking isn't possible. I could expose a position but then it would throw exceptions in a lot of cases.

@adamhathcock commented on GitHub (Jul 20, 2015): A lot of streams are forward-only and don't have a position (e.g. network stream). If you want to have to display something, you could count it yourself. A lot of this library was with decompressing on the fly from gigabyte files or network streams where random seeking isn't possible. I could expose a position but then it would throw exceptions in a lot of cases.
Author
Owner

@weltkante commented on GitHub (Sep 9, 2015):

@thegreatco While that would be useful it would break the stream contract which says that the position property is reserved for seekable streams. You aren't supposed to access the position for nonseekable streams.

If it is done anyways it should be implemented as new properties on the SharpCompress streams and not by overriding the Position property for something it isn't supposed to do.

(PS: The standard thing you do if you need "on the fly" positions is wrapping either the input or output streams in a custom stream subclass and do the counting yourself. That gives you easy hooks for when the writes/reads happen, allowing you to update your progress and having minimum performance overhead.)

@weltkante commented on GitHub (Sep 9, 2015): @thegreatco While that would be useful it would break the [stream contract](https://msdn.microsoft.com/en-us/library/system.io.stream.canseek.aspx) which says that the position property is reserved for seekable streams. You aren't supposed to access the position for nonseekable streams. If it is done anyways it should be implemented as new properties on the SharpCompress streams and not by overriding the Position property for something it isn't supposed to do. (PS: The standard thing you do if you need "on the fly" positions is wrapping either the input or output streams in a custom stream subclass and do the counting yourself. That gives you easy hooks for when the writes/reads happen, allowing you to update your progress and having minimum performance overhead.)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#44