harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
Date Wed, 09 Jun 2010 22:56:15 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877252#action_12877252

Mark Hindess commented on HARMONY-6542:

I've applied your patch at r953177.  Please confirm that it has been applied as expected and
that the issue is resolved.

Normally I ask for confirmation by simply closing this JIRA but I'd like to come up with a
regression test first.  However, I tried using the following (in the context of the existing

    // Regression test for HARMONY-6542
    public void testRandomAccessFile_seekMoreThan2gb() throws IOException {
        RandomAccessFile raf = new RandomAccessFile(f, "rw");
        // write a few bytes so we get more helpful error messages
        // if we land in the wrong places
        assertEquals("seek 0", 1, raf.read());
        assertEquals("seek >2gb", 5, raf.read());
        assertEquals("seek back to 0", 1, raf.read());

and this fails without your fix and passes with it as expected.  Any (by virtue of the use
of sparse files) passes even if less than 2GB of free disk space are available.  However,
this test fails on windows for me even with the fix (though I assume this is because I have
less than 2GB of space available).  Does anyone know how to write a regression test that uses
sparse files on windows?
Or should the above use sparse files and it just doesn't work because the fix is incomplete?

> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to
values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>                 Key: HARMONY-6542
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6542
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>    Affects Versions: 6.0M1, 5.0M13
>         Environment: 32bit Linux/windows
>            Reporter: Ernst Albrecht Köstlin
>         Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
> Dear Community
> .
> Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with
"pos" set to values larger then 0x7FFFFFFF.
> I checked this on Linux  for the 32bit versions of the stable hy6 build (6M1) and also
on the current svn trunk from yesterday (June 2nd 2010).
> This issue was reported  by others to also occur on Linux for the stable hy5 (5M13) build
and on windows for the stable 5/6 builds.
> I checked the stable 64bit version for Linux, to find the issue NOT to occur in there,
seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly
like introduced by the idea that all signed integers on the 32bit version have a maximum lenght
of 32bits. This is not the case for seeking, which should work until seek distances up to
> The underlying os-specific code (linux and windows) does take care of the possibility
of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit
more upper in the calling stack makes those "long distance" calls fail.
> Change this casting does it for windows.
> To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS
64" needs to be set for building.
> I'm not sure if I added this define for the linux build to best place possible, so please
any hy-gurus out there have a look at it.
> I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue
and adds the C-define. It's quite small and it should be easy to addept it to other source
releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or
even the current svn-trunk.
> Thanks and happy hacking...
> Kind regards
> /a

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message