RFR: JDK-8044727: Problem reading the contents of some zip files (original) (raw)
Xueming Shen xueming.shen at oracle.com
Wed Jun 4 19:30:30 UTC 2014
- Previous message: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan
- Next message: RFR: JDK-8044727: Problem reading the contents of some zip files
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
Please help review
issue: https://bugs.openjdk.java.net/browse/JDK-8044727
webrev: http://cr.openjdk.java.net/~sherman/8044727/webrev/
cause: Regression caused by the following changeset:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f [http://cr.openjdk.java.net/~sherman/6303183/webrev]
in which the new implementation of ZipInoutStream.writeLOC() incorrectly tries to always interpret the ZIP64 extra data, if it "exists", even the size/csize fields of the entry have "normal' size data. The original implementation only does the check (and then setting), if at least one of the sizes (entry size and compressed size) has the "zip64 magic value" (this is what the zip64 spec says/requests the implementation to do).
Those "offending" zip files obviously have the extra data with ZIP64 tag (0x0001), but the entry size/csize are "normal"/non-zip64-value.
The change is to back to the correct implementation, only check and set the ZIP64 size(s) if the sizes in the zip entry size fields are "zip64 magic value".
I'm not adding a regression test, as it will force to check in another "binary" zip file into the repository (the ZipOutputStream does not output a "bogus" extra data with ZIP64 tag, if the sizes do not requires a ZIP64 extra data). I've manually verify the fix against the test case attached in the bug report.
Thanks! -Sherman
- Previous message: RFR (JAXP): 8041523:Xerces Update: Serializer improvements from Xalan
- Next message: RFR: JDK-8044727: Problem reading the contents of some zip files
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]