zip64 compatibility problems (original) (raw)

Kumar Srinivasan kumar.x.srinivasan at oracle.com
Wed Jan 16 01:41:06 UTC 2013

On 1/15/2013 1:46 PM, Martin Buchholz wrote:

Hi zip64 team!

It's always a problem creating zip files using new zip spec features, since older zip implementations will fail to read those files. I see the jdk8 fix to allow the launcher to read zip64 files changeset: 5812:f1838d040cc7 user: ksrini date: 2012-09-05 11:38 -0700 7194005: (launcher) needs to be enhanced for 64-bit jar file handling Reviewed-by: darcy, sherman but that has not been backported to jdk7, which seems like a serious problem to me. More generally, most zip implementations, including in the jdk, worked just fine with >64k entries, since the entry count field was generally just treated as a hint. The change to use zip64 when there are >64k entries makes zip files less portable in practice for the next few years. It would have been better to default to writing non-zip64 zip files in such cases. Note that zip 3.0 does write zip64 files for >64k entries, but also provides a flag -fz- to change the default. I'd like to see a backport of 7194005 and am also aware of some other issues with our ugly friend parsemanifest.c. Joe and I contemplated about this, in the end we decided not to, in order to allow for some soak time in jdk8.

You changed calls to open to do this: if ((fd = open(jarfile, ORDONLY #ifdef OLARGEFILE | OLARGEFILE /* large file mode on solaris */ #endif #ifdef OBINARY | OBINARY /* use binary mode on windows */ #endif )) == -1) But this is not done consistently - there are 2 other calls to open in the same file that didn't get the LARGEFILE treatment. Why isn't there a JLIOpen? Maybe if you had reviewed my code changes, you would've caught this. :)

I will look into it, maybe time for a JLI_Open as you suggested.

Kumar

Comments?

More information about the core-libs-dev mailing list