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 parse_manifest.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, O_RDONLY
#ifdef O_LARGEFILE
| O_LARGEFILE /* large file mode on solaris */
#endif
#ifdef O_BINARY
| O_BINARY /* 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 JLI_Open?
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?
