[compress] ZIP64 Progress

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

Hi,

the current version of the zip64 branch is at least able to correctly
uncompress the 5GB file that is contained inside my InfoZIP generated
zip archive.  If anybody wants to give it an early try against archives
created by one of the many other implementations, that would be great.

Right now the corresponding unit tests will just be skipped (using JUnit
4's assume) if the test archives (attached to or linked from
COMPRESS-36) are not present in src/test/resources.  On my aging Linux
Notebook the test, which only checks a small fraction of all bytes read,
takes about 40 seconds.  Initially I tried to check the whole read file
but it took ages.

Next up will be ZipArchiveOutputStream as that should be quite a bit
easier to do than ZipFile and it will allow us to create different sorts
of archives on the fly without falling back to native ZIP
implementations.

As an aside, for JDK7 one can only hope the patchset linked from
http://blogs.oracle.com/xuemingshen/entry/zip64_support_for_4g_zipfile
is not the whole story.  It doesn't touch ZipFile at all and the logic
they use for reading the data descriptor is simply wrong - i.e. they may
fail to read valid ZIP64 archives that don't match their expectations.

It also shows OpenJDK7 needed changes on the native end but I think
those are only in areas that Commons Compress doesn't touch.  We only
use Inflater/Deflater and I think the native changes are in areas that
really work on the archive structure, an area where our implementation
uses pure Java code.

Stefan

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