Hi

Please help review the proposed change for  JDK-8186464.

Issue: https://bugs.openjdk.java.net/browse/JDK-8186464
Webrev: http://cr.openjdk.java.net/~sherman/8186464/webrev

Note:

It appears infozip always adds a ZIP64 format "end" record when there is any entry that needs ZIP64 support, even the ZIP64.end record itself is really not necessary. As the spec suggests, the ZIP64 format record is only needed if any of its fields is too
small to hold the required data, which is not the case in this scenario.

  4.4.1.4 If one of the fields in the end of central directory
      record is too small to hold required data, the field should be
      set to -1 (0xFFFF or 0xFFFFFFFF) and the ZIP64 format record
      should be created.

That said, as Martin pointed out, the spec does not prevent the implementation from adding this ZIP64 format record even it's not necessary. Especially given the fact infozip's implementation is actually doing it, it's reasonable to be liberal here
to accept this layout in our implementation.

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.

thanks,
Sherman

Reply via email to