On Sun, 1 Nov 2020 20:09:32 GMT, Lance Andersen <lan...@openjdk.org> wrote:
> 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 This pull request has now been integrated. Changeset: 6606e090 Author: Lance Andersen <lan...@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/6606e090 Stats: 311 lines in 2 files changed: 272 ins; 29 del; 10 mod 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/987
