Visual Studio and .NET Framework Home
GzipStream - Cannot decompress binary concatenated gzip files
as Won't Fix
7/25/2008 7:18:01 AM
User(s) can reproduce this bug
GzipStream's current impletation to framework 3.5 is not able to decompress binary concatenated gzip files.
.NET Framework 3.5
Operating System Language
Steps to Reproduce
1. Create a binary concatenated file
- copy /b file1.gz + file2.gz file_out.gz
2. Decompress file using GZipStream
The decompressed contents belong to first input file. File file1.gz in our case.
GZipStream should read until the end of actual compressed data i.e. file1.gz and file2.gz contents should be read in continuation.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 2/28/2011 at 5:59 AM
.Net 4 still has this bug.
AFAICT, the GZipStream implementation is *not* RFC1952 compliant because of this bug. The RFC (http://www.faqs.org/rfcs/rfc1952.html) allows a "series of members (compressed data sets)".
Most (but not all) of the available unpackers like 7zip, WinRar, ... will unpack such a file successfully.
They all show wrong file length though :-)
Such files may come from web services which is a big show stopper for a .Net client.
on 8/17/2010 at 12:18 AM
Are we going to revisit the same and fix the behavior?
on 12/10/2008 at 4:03 PM
Thank you for the suggestion! Your feedback is very valuable to us. We looked into this and due to other competing priorities for the release, we have decided not to invest in adding support for concatenated streams to the next release of the .NET Framework. So you'll have to continue working around this by pinvoking the native zlib library. However, we are interested in rounding out our compression APIs in the future, so we may revisit this, along with adding support for more compressed archive formats.
Given the above, I’m going to go ahead and resolve this bug as Won’t Fix. If you have any other comments or feedback about this, feel free to reactivate the bug.
Justin Van Patten
Base Class Libraries
on 8/15/2008 at 4:24 AM
I agree to what you are saying pshaffer :) The very item that brings me to this place is the fact that decompression using zlib 1.2.3 (in native C++) works fine even on binary concatenated file. Our team has been writing C++ applications using zlib library since past 3 years, and we process very large volumes of data (in some cases upto 8 GB of compressed gzip file!). We do not create merged files using gzip algo again, instead we binary concatenate them; all because of the virtue of zlib1.2.3 :)
Had to come to support as I was working on a viewer that lets a user to view those files in .NET GUI - and damn I am stuck here.
By the way for the time being I am making platform invoke to zlib dll, but will definitely like to revert back to framework classes ;)
on 7/31/2008 at 3:33 PM
gzip supports concatenating compressed files together: http://www.manpagez.com/man/1/gzip/ (see advanced usage section)
on 7/28/2008 at 8:34 PM
We were able to reproduce the issue you are seeing. We are escalating this bug to the product unit who works on that specific feature area. The product team will review this issue and make a decision on whether they will fix it or not for the next release
on 7/28/2008 at 6:37 PM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com/)
on 7/25/2008 at 10:46 AM
I would not expect for that to be a valid usage scenario. Normally a compression algorithm has to make certain assumptions about the beginning and ending of the stream. Usually its that the beginning of the stream it's reading is, in fact, the start of the stream and that the stream should be read until the very end. By concatenating, you've got both an end and a beginning stuck in the middle with no way for the GZIP stream to know that it should have stopped reading and restarted on the separately compressed stream.
By way of example, take a 3rd party zip tool and generate two zip files. Concatenate them together using the same technique and see if you can then open and unzip the resulting single file. Bet that it fails. While not an exact correlation, its still the same concept.
to post a workaround.
Please enter a workaround.
© 2014 Microsoft