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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
