Re: [Evolution-hackers] compression for folders?

[Jeffrey Stedfast <fejj ximian com>]

On Mon, 2004-05-10 at 19:33, Ray Lee wrote:
> On Mon, 2004-05-10 at 16:09, Jeffrey Stedfast wrote:
> > clearly zcat is doing something funky because gzip files have an 8byte
> > footer that would foul up any code that tried to read that file if it
> > were mbox.
> 
> It's not doing anything funky. The gzip format (which is different than
> the compress format) is a concatenation of 'members,' each of which is a
> compressed chunk. It knows when to stop by when it hits EOF.
> 
> > it's not trivial to do what zcat does.
> 
> That's why the powers that be gave us zlib :-).

gzip has a 10 byte header followed by optional blocks followed by the
compressed data with an 8byte crc32/isize value at the end of the file.
That's how it's specified.

the header doesn't contain a length value so you don't know how long it
is. the only thing I can come up with is that zcat must keep a running
crc32/isize and must compare it to the input stream as it goes to find
the end. this sucks.

zlib doesn't exactly make it any easier. trust me. I wrote a stream
filter today to do gzip and it was an ugly pita.

> 
> > besides, note "archive". yes, compressing archive folders was never
> > the issue, the issue was compressing all folders.
> 
> My bad, I missed the context there.

np

Jeff

> 
> Ray
>