zip64 compatibility problems

Kumar Srinivasan kumar.x.srinivasan at oracle.com
Sat Jan 26 20:11:39 UTC 2013


On 1/26/2013 9:14 AM, Martin Buchholz wrote:
>
>
> On Tue, Jan 15, 2013 at 5:41 PM, Kumar Srinivasan 
> <kumar.x.srinivasan at oracle.com <mailto:kumar.x.srinivasan at oracle.com>> 
> wrote:
>
>
>
>         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.
>
>
> Following up on this, I have a simple webrev:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/LARGEFILE/ 
> <http://cr.openjdk.java.net/%7Emartin/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.
To be perfectly honest, I am swamped right now, I will try to fit this in.
Sherman if you have cycles then go for it, I will help as needed.

Kumar





More information about the core-libs-dev mailing list