Re: [RFC]: Pack-file object format for individual objects (Was: Revisiting large binary files issue.)

From: Linus Torvalds <torvalds@osdl.org>
Date: Jul 11, 2006, 22:17 UTC
Message-ID: <Pine.LNX.4.64.0607111512420.5623@g5.osdl.org>
In-Reply-To: <44B41BFD.8010808@stephan-feder.de>

On Tue, 11 Jul 2006, sf wrote:

> 
> Just look at the first byte of the object file _without doing any
> decompression_. It is 0x78 _if and only if_ the object file is in the
> traditional format.

0x78 isn't the only valid flag for a zlib stream, as far as I can tell.

It may be the only one _in_practice_, of course, but the zlib standard defines the first byte as

 - for low bits: CM (compression method):

        "This identifies the compression method used in the file. CM = 8
         denotes the "deflate" compression method with a window size up
         to 32K.  This is the method used by gzip and PNG (see
         references [1] and [2] in Chapter 3, below, for the reference
         documents).  CM = 15 is reserved.  It might be used in a future
         version of this specification to indicate the presence of an
         extra field before the compressed data."

 - four high bits are CINFO:

        "For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
         size, minus eight (CINFO=7 indicates a 32K window size). Values
         of CINFO above 7 are not allowed in this version of the
         specification.  CINFO is not defined in this specification for
         CM not equal to 8."

so 0x78 means "deflate with 32kB window size", but I don't see anything guaranteeing that we might not see something else for an object that cannot be compressed, for example.

Anyway, the good news is that _if_ 0x78 is indeed the only possible value, then it is also an illegal value for an unpacked object in pack-file format (type=7 being OBJ_DELTA) and we wouldn't need any other flag for this.

I just don't know if it's the only possible one..

		Linus