Subject: RE: LOCKT vs. POSIX fcntl(F_GETLK,...)

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 6 Feb 2001 09:13:46 -0800

> The LOCKT operation returns a LOCK4denied structure if a conflicting lock
> is found.  This structure contains
>   - the owner of the conflicting lock, and
>   - the endpoints of the conflicting lock (i.e., offset and range)
> However, the POSIX system call for lock testing, fcntl(F_GETLK, ...), must
> return (in the case of a conflicting lock)
>   - the owner of the conflicting lock,
>   - the endpoints of the conflicting lock, and
>   - the type of the conflicting lock (i.e., whether a read or write lock)
> Consequently, the protocol does not quite allow implementation of the
> POSIX semantics for lock testing.  The easiest solution would seem to be
> the addition of a "type" field to the definition of 'struct LOCK4denied'.
> Is the addition of such a field still possible at this point?  Any other
> suggestions?     - Kendrick

As has been mentioned in other mail, there are lots of problems with
POSIX lock testing semantics that arise because there are "more things
in heaven and earth than are dreamt of in" the world according to
posix.  Anything involving lockowners on multiple clients is going to
run afoul of that.

However, in this case, we have a situation in which something that works
for a set of processes on a single system might cease working when the
filesystem is nfs, even though all of the processes involved are running
on a single system (i.e. no real issues of distribution).  Users might 
(justifiably) take a particularly dim view of that.

It looks like we just made a mistake here.  Let's say "Oops!" and fix it.

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Wed, 7 Feb 2001 17:17:21 -0500 (EST)

> It looks like we just made a mistake here.  Let's say "Oops!" and fix it.

I agree, particularly since I think the fix will require a very minor
change, both in terms of changes to the spec and changes to existing
server implementations.  I would like to make a "formal proposal" to
change the definition of 'struct LOCK4denied' in the protocol from

     struct LOCK4denied {
             nfs_lockowner4  owner;
             offset4         offset;
             length4         length;
     };

to

     struct LOCK4denied {
             nfs_lockowner4  owner;
             offset4         offset;
             length4         length;
             nfs_lock_type4  locktype;
     };

for purposes of improving a POSIX client's ability to map the NFSv4 file
locking semantics to its own.

Kendrick