Using a MemoryStream with GZipStream [Lakshan Fernando]

re: Using a MemoryStream with GZipStream [Lakshan Fernando]

janmoorlag — Wed, 10 May 2006 18:05:33 GMT

Interesting Finds

Jason Haley — Thu, 11 May 2006 05:48:57 GMT

re: Using a MemoryStream with GZipStream [Lakshan Fernando]

FullMetal — Thu, 11 May 2006 11:11:13 GMT

Isn't it a really a non-intuitive behaviour? What is the reason for this strange design decision?

re: Using a MemoryStream with GZipStream [Lakshan Fernando]

David Levine — Thu, 11 May 2006 15:11:44 GMT

I agree that this behavior is not obvious - it would be useful to reconsider the design.

The GZip class itself could provide a ToArray method; this would eliminate the need to concern ourselves with the state of the the Stream object, either within or outside the scope of the using statement. The semantics of ToArray could include appending the footer info to the array without closing the zip stream.

Also...
the code:

using (GZipStream zip = new GZipStream(stream, CompressionMode.Compress)

will set the internal _leaveOpen field to a value of false, which means that when the zip closes it also closes the underlying stream, so when the code exits the scope of the 'using' statement it closes the MemoryStream - attempts to access the length throw an exception. It should be changed to:

using (GZipStream zip = new GZipStream(stream, CompressionMode.Compress,true)
{
}
// access MemoryStream object here...
buffer = ms.ToArray();

It would also be goodness if the ZIP classes provided better compression - I can only get about a 78% compression ratio on a pure text file - I was getting about a 98% ratio using other libraries. Will this be improved in future versions?

re: Using a MemoryStream with GZipStream [Lakshan Fernando]

David Levine — Thu, 11 May 2006 15:17:36 GMT

Correction...

stream.ToArray() does indeed work after closing the stream, but accessing the field
stream.Length throws an exception, which is extremely non-intuitive. They should either both work or both not work. And it strikes me as odd (and possibly a security hole) that I can successful convert a closed stream to a valid array.

re: Using a MemoryStream with GZipStream [Lakshan Fernando]

dls — Mon, 15 May 2006 21:57:08 GMT

It sounds like your customers are seeing the GZipStream retain some data due to compression block sizes. Would it be better to call the Flush method rather than relying on the implicit flush during close?

re: Using a MemoryStream with GZipStream [Lakshan Fernando]

Lakshan Fernando — Tue, 16 May 2006 18:29:14 GMT

Thanks a lot for your comments.

The footer information is written at GZipStream.Dispose() time and this means that the MemoryStream doesn't have complete data until its closed. As mention earlier, this is not an issue with FileStream since the common usage incorporates Close before decompressing the bits. It seems unintuitive when using the MemoryStream.

We are looking into addressing performance and size issues of GZipStream in a future release.
Thanks
Lakshan Fernando
BCL Team

An Issue Using A MemoryStream with the Compression classes

Darth Coder.Net - Jon Wojtowicz [MVP] — Tue, 10 Oct 2006 18:29:45 GMT

While working on compressing view state for web pages I encountered an issue in using the compression...