zip64 compatibility problems

[Martin Buchholz]

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
>> off_t is signed 32-bit.
>> - As we discussed, it might be better to have a JLI_Open (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.
>