Re: zip64 format not streamable?

> > ... 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.

Yes.  It would seem that setting these to the Zip64 flag values would be
the way to do it.

> > 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.

I guess could set bit 3, set the local fields to 0, create a Zip64 extra
field, set those to 0 (the appnote almost implies this), then use Zip64
fields in the following data descriptor.  I think that meets all the
appnote requirements but I have no idea if it's right.  For streams just
assume Zip64 is needed maybe at the beginning as can have normal values
in a Zip64 field.  This forces using a version 4.5 unzip though.

> > 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).

It would have to be PKZip 4.5 or better (with command line simulation if
needed).  I did some tests with all this many months ago but I never
resolved the streaming issue.  I might do some more checking this
weekend maybe.

> > 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.

You'd probably be replied to directly so no problem there.

Ed