[Compress] COMPRESS-538 : about Zip64

[Peter Lee <pe...@gmail.com>]

Hi all,

The recent issue COMPRESS-538 talks about the zip64 extra field in Local
File Header.

Currently we will add a Zip64 extra field for the entries with uncompressed
size unspecified. And we will update the zip64 extra field in
ZipArchiveOutputStream.rewriteSizesAndCrc a little bit : if we actually
doesn't need a Zip64 extra, we will not remove it. Instead we keep it in
Local File Header, and we update the 'Zip Version Needed to Extract' to the
ones without zip64. Then we removed the extra field(after it's already
written to the zip archive) to avoid the zip64 written to the Central
Directory.

Not sure why we are doing it like that. Shouldn't we remove the zip64 extra
field if it is not actually necessary(when the Zip64Mode is not
Zip64Mode.Always)? We could do this in
ZipArchiveOutputStream.rewriteSizesAndCrc cause we know the compressed size
and uncompressed size here. In my opinion we should remove the zip64 extra
field when mode != Zip64Mode.Always && actuallyNeedsZip64 == false.

Thoughts?

cheers,
Lee

Re: [Compress] COMPRESS-538 : about Zip64

[Stefan Bodewig <bo...@apache.org>]

On 2020-06-28, Peter Lee wrote:

> Currently we will add a Zip64 extra field for the entries with uncompressed
> size unspecified. And we will update the zip64 extra field in
> ZipArchiveOutputStream.rewriteSizesAndCrc a little bit : if we actually
> doesn't need a Zip64 extra, we will not remove it. Instead we keep it in
> Local File Header, and we update the 'Zip Version Needed to Extract' to the
> ones without zip64. Then we removed the extra field(after it's already
> written to the zip archive) to avoid the zip64 written to the Central
> Directory.

> Not sure why we are doing it like that.

We only know the sizes once we've written the entry's content to the
archive. The content is behind the extra field. Removing the extra field
from the archive would require us move all content a few bytes towards
the front of the archive. Potentially a lot of effort which will only
gain us a few bytes.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org