commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject [compress] Some ZIP64 Interop Results
Date Mon, 01 Aug 2011 14:49:45 GMT

I've checked current trunk's ZipArchiveInputStream and
ZipArchiveOutputStream implementations against InfoZIP's zip (Cygwin in
this case), 7ZIP, windows Compressed Folders and Oracle's final Java7
JDK's jar command - all on Windows 7.

For InputStream I've created an archive with a single compressed entry
of 5 billion zeros with each of the tools as well as one archive with
100k files of size 0bytes each.

Windows Compressed Folders uses a compression method that we don't
support (Deflate64, method number 9) and it seems to be a good idea as
the resulting archive is 168kB rather than the 4.6MB created by all
other tools.  Anyway, this archive can not be used in tests.

All other archives are read correctly by ZipArchiveInputStream, there is
a problem with reading the size of the big entry inside the archive
created by jar, but this clearly is a bug in Java7 and I'm going to
report it against OpenJDK[1] (and may have a workaround, need to think
about it a bit longer).

If you remove all @Ignores from ZIP64SupportTest and comment the two
f.delete[OnExit] lines you end up with 16 archives testing a lot of
ZIP64 features, all of them created by ZipArchiveOutputStream.

InfoZIP and Windows Compressed Folders consider all 16 of them valid,
7ZIP doesn't like the one that writes 100k files to a non-seekable
stream and jar dies on the three archives that write big deflated
entries.  I'll investigate this further but suspect that there is
another bug in jar (while I trust 7ZIP at this point).

As far as performance goes trunk is on par with InfoZIP's ZIP and jar,
likely because all three of them use ZLIB under the covers.  7ZIP is
significantly faster but seems to choose a lower compression level,
Windows Compressed Folders is fast on some and quick on other archives.


[1] Once I manage to set finalize the account creation process at the
bug database, that is.  Do they really think I'd give them my business
phone number and street address in order to report a bug?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message