zip64 compatibility problems (original) (raw)
Martin Buchholz martinrb at google.com
Sat Jan 26 17:14:03 UTC 2013
- Previous message: zip64 compatibility problems
- Next message: zip64 compatibility problems
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 15, 2013 at 5:41 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote:
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 JLIOpen as you suggested.
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 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.
- Previous message: zip64 compatibility problems
- Next message: zip64 compatibility problems
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]