Steps to reproduce
- use a non-seekable stream
- attempt to store data in it. - using the store compression method
- it gets set as deflation method, but with 0% compression.
Expected behavior
Tell us what should happen
it should be stored and not encrypted.
Actual behavior
Tell us what happens instead
it gets run through the compression algorithm, albeit with no compression.
Version of SharpZipLib
1.2.0
Obtained from (only keep the relevant lines)
- Package installed using NuGet (via dotnet add)
we have noticed at least some performance impact from not just copying the data, i am returning the zip on the fly from a web api as a stream, this means i cannot have a seekable stream.
i am zipping several large (40MB+) pdf and tiff images, that only slow down the compression, in the previous api we used DotNetZip and it worked fine and fast.
it took my some time via digging through your code and debugging what a 'can patch' stream is.
but is there any way of doing this as part of a write only stream? why does the stream need to be patchable?
Steps to reproduce
Expected behavior
Tell us what should happen
it should be stored and not encrypted.
Actual behavior
Tell us what happens instead
it gets run through the compression algorithm, albeit with no compression.
Version of SharpZipLib
1.2.0
Obtained from (only keep the relevant lines)
we have noticed at least some performance impact from not just copying the data, i am returning the zip on the fly from a web api as a stream, this means i cannot have a seekable stream.
i am zipping several large (40MB+) pdf and tiff images, that only slow down the compression, in the previous api we used DotNetZip and it worked fine and fast.
it took my some time via digging through your code and debugging what a 'can patch' stream is.
but is there any way of doing this as part of a write only stream? why does the stream need to be patchable?