Tiago de Paula Peixoto wrote:
On 10/30/2005 10:34 PM, Jonathan Turkanis wrote:
gzip_compressor works as follows: The first time you write data to it, it writes the gzip header information to the downstream Sink, and then writes the beginning of the compressed data. When the filter is closed, it writes any compressed data that has been buffered, plus the gzip footer, which consists of a checksum and the length of the uncompressed data.
In the above example, the filter is automatically closed at the end of main; this causes the gzip footer to be written. But since no data was ever compressed, the gzip header has never been written.
I guess this is a bug of some sort. What behavior would you expect in this case? It seems to me it would make the most sense to output data in the gzip format representing a 0-length file.
That would also make sense to me, but it would be inconsistent with the bzip2_compressor behavior, which doesn't write any footer if there was no header.
I can't really change the behavior of bzip2, since it's just a wrapper around libbz2, whereas with gzip I implemented the header and footers myself. I wouldn't worry too much about consistency, since this is a corner case.
And also it would create an impossibility of just visiting a file in append mode, without writing any data to it.
I don't follow. What do you want to be able to do?
This could be fixed if gzip_compressor were seekable. Is this possible to be implemented?
The only way I can see to implement this would be to buffer all i/o and only compress or decompress it when the stream is closed. This could be implemented as an adapter that would work with almost any filter, so I wouldn't want to build it into gzip. I'll put this on my list of possibilities for 1.34.
Is this an intended feature?
-- Jonathan Turkanis www.kangaroologic.com