RFR JDK-8186464: ZipFile cannot read some InfoZip ZIP64 zip files

[Xueming Shen]

How about to add an option to our zipfs to force the ZIP64 end record when
enabled. Harmless if not specified.

Just try to avoid adding yet another shell test case ...

http://cr.openjdk.java.net/~sherman/8186464/webrev

On 08/22/2017 12:17 PM, Martin Buchholz wrote:
>
>
> On Mon, Aug 21, 2017 at 6:35 PM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote:
>
>
>     I have manually verified the change does fix the problem (either use the jar tf or
>     java jdk.nio.zipfs.ZipInfo to check the offending zip file). Given the nature of the
>     test case, I'm hesitated to add this test as a unit/regression into the repo for now.
>
>
> Testability is one of the serious problems with ZIP64, since even in 2017 it's still unreasonable to create 5GB files in a test.
> I think we should have a standard way to mark and optionally run expensive tests, as we do in j.u.concurrent with -Djsr166.expensiveTests=true.  But we're not going to fix that here.
>
> There is one giant benefit of zip's annoying creation of a ZIP64 END header.  It allows us to write tests that aren't too expensive (but they do rely on zip being available on the test machine).
>
> This command:
> echo hello | zip infozip.zip -
> creates a very small zip file with a ZIP64 END header.  For bonus points, check that everything still works if you prepend some data, with or without running "zip -A" on it.  We should do this.