Home Dashboard Directory Help
Search

GzipStream - Cannot decompress binary concatenated gzip files by Robin Debnath


Status: 

Closed
 as Won't Fix Help for as Won't Fix


2
0
Sign in
to vote
Type: Bug
ID: 357758
Opened: 7/25/2008 7:18:01 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

GzipStream's current impletation to framework 3.5 is not able to decompress binary concatenated gzip files.
Details
Sign in to post a comment.
Posted by ujr 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.
Posted by Robin Debnath on 8/17/2010 at 12:18 AM
Are we going to revisit the same and fix the behavior?
Posted by Microsoft on 12/10/2008 at 4:03 PM
Robin Debnath,

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.

Thanks!

Justin Van Patten
Program Manager
Base Class Libraries
Posted by Robin Debnath 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 ;)
Posted by Brian Cole 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)
Posted by Microsoft 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
Posted by Microsoft 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/)
Posted by PShaffer 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.
Sign in to post a workaround.