On Sunday, February 11, 2007 01:52:31 PM -0800 Adam Megacz <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
