Hi,

Please review the fix for JDK-8255380 which addresses an issue when the Zip 
file is > 4GB.  Zip FS when processing the CEN extra data does not take into 
account the fact that there is no specific order to how the extra data fields 
are written.  Info-ZIP writes the fields in a different order than Zip FS which 
presents a problem when evaluating the Info-ZIP extended timestamp and the LOC 
offset is 0XFFFFFFFF therefore the LOC offset needs to be read from the 
EXTID_ZIP64 extra data prior to attempting to read the LOC extra data field.

The fix will defer reading of the LOC extra data field, if needed until all of 
the CEN extra data has been processed.

Using jdk.nio.zipfs.ZipInfo, you can see the ordering difference of the CEND 
extra data fields when using Zip FS and info-zip.

Info-zip is included with Mac OS so the test uses ProcessBuilder to execute zip 
on Mac OS and Linux.  

Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly.

Best,
Lance

-------------

Commit messages:
 - (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false

Changes: https://git.openjdk.java.net/jdk/pull/987/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=987&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255380
  Stats: 311 lines in 2 files changed: 272 ins; 29 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/987.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/987/head:pull/987

PR: https://git.openjdk.java.net/jdk/pull/987

Reply via email to