Add option to leave base stream open when disposing #600

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

Originally created by @RayCarrot on GitHub (Nov 11, 2023).

Currently when disposing a compression stream such as ZlibStream it will also dispose the base stream you passed in. There are however times where you still want the base stream to remain open for further use and currently the only way I could find to do this is by creating a wrapping stream which doesn't dispose.
My suggestion would be to do what most built-in .NET streams do and have a parameter in the constructor called leaveOpen which indicates if the base stream you pass in should be left open even after disposing.

Originally created by @RayCarrot on GitHub (Nov 11, 2023). Currently when disposing a compression stream such as `ZlibStream` it will also dispose the base stream you passed in. There are however times where you still want the base stream to remain open for further use and currently the only way I could find to do this is by creating a wrapping stream which doesn't dispose. My suggestion would be to do what most built-in .NET streams do and have a parameter in the constructor called `leaveOpen` which indicates if the base stream you pass in should be left open even after disposing.
claunia added the enhancementbug labels 2026-01-29 22:14:24 +00:00
Author
Owner

@adamhathcock commented on GitHub (Nov 13, 2023):

We shouldn't be disposing streams we didn't create. A lot of StreamReaders and whatnot do dispose.

Please show what usage disposes unexpectedly

@adamhathcock commented on GitHub (Nov 13, 2023): We shouldn't be disposing streams we didn't create. A lot of StreamReaders and whatnot do dispose. Please show what usage disposes unexpectedly
Author
Owner

@RayCarrot commented on GitHub (Nov 14, 2023):

Your implementation of ZlibStream disposes the stream you pass in when disposing the ZlibStream. It happens here as far as I can tell.
I also checked the usage docs which say "I've decided to always close wrapped streams as of 0.21". The suggestion there is to use a wrapper stream, like I currently do, to avoid disposing. However I would suggest having the option to leave the stream open with a bool parameter just like the standard .NET libraries do. This avoids any additional overhead added by a wrapping stream.

@RayCarrot commented on GitHub (Nov 14, 2023): Your implementation of `ZlibStream` disposes the stream you pass in when disposing the ZlibStream. It happens [here](https://github.com/adamhathcock/sharpcompress/blob/7d9c875c4d7827a812f6dfc195d1e3a6dca37fba/src/SharpCompress/Compressors/Deflate/ZlibBaseStream.cs#L351) as far as I can tell. I also checked the [usage docs](https://github.com/adamhathcock/sharpcompress/blob/master/USAGE.md) which say "I've decided to always close wrapped streams as of 0.21". The suggestion there is to use a wrapper stream, like I currently do, to avoid disposing. However I would suggest having the option to leave the stream open with a bool parameter just like the standard .NET libraries do. This avoids any additional overhead added by a wrapping stream.
Author
Owner

@Erior commented on GitHub (Jan 11, 2024):

Options "LeaveStreamOpen" true/false
Think we have tests regarding dispose, are you using ZlibStream directly or what is the scenario?

@Erior commented on GitHub (Jan 11, 2024): Options "LeaveStreamOpen" true/false Think we have tests regarding dispose, are you using ZlibStream directly or what is the scenario?
Author
Owner

@RayCarrot commented on GitHub (Jan 11, 2024):

I am using ZlibStream directly, yes. And from what I can tell that's the only option in this library. Currently I made my own wrapper stream to avoid disposing, but I'd prefer if there was simply an option in the API directly like there is in the streams in the .NET libraries. There should be a difference between wanting to dispose the compression stream and whatever data it might be using and the base stream that you pass in.

@RayCarrot commented on GitHub (Jan 11, 2024): I am using ZlibStream directly, yes. And from what I can tell that's the only option in this library. Currently I made my own wrapper stream to avoid disposing, but I'd prefer if there was simply an option in the API directly like there is in the streams in the .NET libraries. There should be a difference between wanting to dispose the compression stream and whatever data it might be using and the base stream that you pass in.
Author
Owner

@adamhathcock commented on GitHub (Jan 12, 2024):

It can be a feature added, I think the compression streams directly haven't been changed to respond to that option

@adamhathcock commented on GitHub (Jan 12, 2024): It can be a feature added, I think the compression streams directly haven't been changed to respond to that option
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#600