The customers application does not boot when the
application tries to lock files hosted on an NFSv3 file system running on HP-UX 11.23 which checks the 'len' argument against the maximum file size and returns error.

The java.nio.channels.FileChannel.tryLock() implementation translates into the following system call:

fcntl64(17, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0,
len=9223372036854775807}, 0xbfffd0e0)

where len argument is set to maximum of long type ( 2^63 - 1  ==
9223372036854775807 ).

This causes problem when using HP-UX 11.23 NFS server, which checks the 'len' argument against the maximum file size and returns error, which is correspondent with NFSv3 rfc document.

  To lock the whole file the 'len' argument should be set to 0.
eg. have an OS call translate into the following:

fcntl64(17, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0},0xbfffd0e0)

which is also documented in fcntl manual page.

Supposedly this is an incorrect implementation of locking the whole file in the SUN jdk and would like it to be fixed using zero length lock offset size.

Analysis shows that java.nio.channels.FileChannel.tryLock() is implemented
as:

    public final FileLock tryLock() throws IOException
    {    return tryLock(0L, 0x7fffffffffffffffL, false);     }

The customer would prefer:

    public final FileLock tryLock() throws IOException
    {    return tryLock(0L, 0x0L, false);
Posted Date : 2007-11-12 15:49:58.0

Not use NFS on HPUX for application files - this is difficult for the customer.

Where the position is 0 and the size is Long.MAX_VALUE then we should set l_len to 0. Will fix in jdk7. This issue can be worked around by the 3-arg tryLock method, eg:
    FileLock lock = fc.tryLock(0, fc.size(), false);
Posted Date : 2008-03-12 10:11:36.0