zip64 compatibility problems (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Mon Jan 28 11:36:46 UTC 2013
- Previous message: zip64 compatibility problems
- Next message: Codereview request for 8003680: JSR 310: Date/Time API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/ 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 O_LARGEFILE flag. That might be something for future refactoring (I think JLI_Open 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.
- Previous message: zip64 compatibility problems
- Next message: Codereview request for 8003680: JSR 310: Date/Time API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]