Re: zip64 format not streamable?

Mark,

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

As it turns out if bit 3 is set the values are read from the data
descriptor as expected.  If there is a Zip64 extra field these values
are Zip64 values.  The extra field can have 0 for the sizes as these
values will come from the data descriptor following the file.

For the Zip64 case the standard fields will have 0xffffffff as needed,
the extra field values can be 0, and the Zip64 actual compressed and
uncompressed sizes go in the data descriptor.

This means that when streaming the user must decide ahead of time if it
will be a Zip64 entry.  Other than that it seems to stream based on my
limited tests with split and spanned archives.

Ed