[OpenAFS-devel] Java VM native libs call flock() with l_len=0x7fffffff00000000

[Jeffrey Hutzelman]

On Sunday, February 11, 2007 01:52:31 PM -0800 Adam Megacz 
<megacz@cs.berkeley.edu> wrote:

>
> Strange, huh?  I was eventually able to track down the source of the
> "afs: warning byte-range lock/unlock ignored" with the help of Matt's
> patch.
>
> It appears that Sun's JVM (and perhaps others) have only one low-level
> C routine for requesting locks from the OS.  That routine is a
> byte-range locking routine.  To implement the higher-level "lock this
> entire file" API (FileChannel.tryLock()), the libraries (written in
> Java) invoke the low-level C routine with the file length set to -1.
> This constant is provided as a *Java long*, which is always 64 signed
> bits regardless of OS or CPU.
>
> Anyways, the ultimate result is that AFS winds up getting a lock
> request like this:
>
>    l_start  = 0
>    l_whence = 0
>    l_len    = 0x7fffffff00000000
>
> Clearly this is a Java bug

Yeah, no kidding.  The correct value for l_len here is 0.

> Since it's also unlikely that any file is ever going to be
> anywhere close to being (unsigned)0x7fffffff00000000 bytes long (more
> than 2^63), the patch below has OpenAFS interpret such requests as
> whole-file locks.

I can't think of any reason not to do this, but I'd suggest treating only 
that one value specially, rather than any value over (2^31-1) << 32

If you haven't yet sent a message to openafs-bugs with this patch, you 
should do so.

-- Jeff