Re: zip64 format not streamable?

On Monday, September 15, 2003, at 07:19 PM, EG wrote:
> Reading the appnote (version 5.2, the first one I found) it seems in
> that case the size fields in the local header could be set to 
> 0xFFFFFFFF
> (Zip64 flag value) and if bit 3 is set the actual sizes put in the
> following descriptor.  That is not what the standard says though as 
> when
> bit 3 is set these need to be zero in the local header.

And therein lays the dilemma.

> Could also detect the existence of a Zip64 extra field (could have all
> zeros) and if exists and bit 3 set then data descriptor follows and is
> Zip64.  The appnote does not mention that either but it follows.

According to the description, the extra field is written only if 
needed, but that is not known at the time the local header is written 
when streaming.  Furthermore, the lengths are not known, so the extra 
field wouldn't have any of those in it.  At least that would be 
consistent with those fields having zeros in them, since the appnote 
says that the lengths are present in the extra field only if the 
corresponding fields in the local header are all ones.

> PKZip apparently can read
> archives with this bit set though as long as the right format is used
> (including a data descriptor signature).  As far as I can tell anyway.

That's really the key, since pkunzip is the ultimate arbiter of 
ambiguities in the format.  Whatever pkunzip can unzip is the answer to 
the question.  However I don't have and can't run pkunzip, being sans 
Wintel machine (and rather pleased about that).

> By the way, you may want to also mail Zip-Bugs.

Except that I wouldn't see the response since I don't subscribe to that.

mark