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 > _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
