[Boost-bugs] [Boost C++ Libraries] #1896: boost::iostreams::gzip_decompressor silently ignores multiple members

Subject: [Boost-bugs] [Boost C++ Libraries] #1896: boost::iostreams::gzip_decompressor silently ignores multiple members
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-05-05 10:02:49


#1896: boost::iostreams::gzip_decompressor silently ignores multiple members
------------------------------------------------+---------------------------
 Reporter: Bruce MacDonald <bruce_at_[hidden]> | Owner: turkanis
     Type: Bugs | Status: new
Milestone: Boost 1.36.0 | Component: iostreams
  Version: Boost 1.35.0 | Severity: Problem
 Keywords: iostreams gzip gzip_decompressor |
------------------------------------------------+---------------------------
 The gzip file format RFC 1952 allows for the concatenation of multiple
 "members" in one gzip file. I have a provider who, unfortunately, sends
 me gzipped files which consist of about 8 500M (uncompressed) members. Why
 they are doing this I don't know, but this seems to be a long standing
 weirdness with gzip. The gzip command line utility simply decompresses
 all the members in a single stream and this is the behaviour I would
 expect from gzip_decompressor.

 The gzip_decompressor only processes the first member and silently ignores
 the others. In fact, the implementation of read_footer attempts to slurp
 the rest of the compressed file into a string which it then discards.

 In order to read the rest of the members all we have to do is read and
 process the actual trailer (8 bytes) and then recursively process the rest
 of the input (perhaps after invoking close() on ourself?).

 I have attempted to write a fix for this myself but have been defeated by
 the complexity of the library.

--
Ticket URL: <http://svn.boost.org/trac/boost/ticket/1896>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.


This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:57 UTC