zip64 compatibility problems (original) (raw)

Martin Buchholz martinrb at google.com
Thu Feb 7 02:03:22 UTC 2013

Pushed into tl8. Thanks for the reviews!

On Mon, Jan 28, 2013 at 3:36 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

On 26/01/2013 17:14, Martin Buchholz wrote:

: Following up on this, I have a simple webrev:

http://cr.openjdk.java.net/**martin/webrevs/openjdk8/**LARGEFILE/<http://cr.openjdk.java.net/martin/webrevs/openjdk8/LARGEFILE/> with an "obviously correct" fix. However: - we need a bug filed - This change is completely untested. I no longer have access to native 32-bit systems where this bug might be manifested. I have not tried to actually provoke a failure, although it should not be too hard to create a 3GB jar file with the contents of interest at the end, on a system where offt is signed 32-bit. - As we discussed, it might be better to have a JLIOpen (or even better, common C-level infrastructure for the whole project) but only you guys have access to the variety of systems to write and test such a thing, even if it is just a few lines of code. So next step here is up to you. I've created a bug to track this first installation: 8006995: java launcher fails top en executable JAR > 2GB I think the proposed changes are okay, a no-brainer really. It would be nice if the open were moved to platform specific code, then we could use open64 and drop OLARGEFILE flag. That might be something for future refactoring (I think JLIOpen was suggested in an earlier mail). Ideally we should have a test but we've had a lot of bad experience with files that need multi-GB zip files (slow, need lots of disk space) so I think it would be saner to leave it out this time. -Alan.

More information about the core-libs-dev mailing list