Subject: RE: interpretation of LOCK usage (open_to_lock_owner4 usage)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Dec 2002 13:15:10 -0800

I definitely agree that this should be an error.

The spec is not very clear on this issue so it is hard to
tell what error is "right".  Since this doesn't really fit 
in any of the categories, you could argue INVAL but that 
would make it really hard for the client to find out what
is wrong.  I think BAD_SEQID is probably the best choice.

It looks like my code returns OLD_STATEID in this case and 
that seems really bogus.  I'll change it to BAD_SEQID or
whatever else turns out to be the general consensus.  

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, December 11, 2002 4:08 PM
To: [email-masked]
Subject: interpretation of LOCK usage (open_to_lock_owner4 usage)

I am posting to convey my interpretation of dealing with a particular
scenario involving LOCK operation usage.

The scenario is:

Client sends a LOCK with the new_lock_owner specified and provides a
lock_owner (LO1).  The server responds to this appropriately.

The client send zero or more LOCK/LOCKU operations but does not send a
RELEASE_LOCKOWNER operation for LO1 and the file is still open.

The client sends a new LOCK request with new_lock_owner specified and
provides the same lock_owner (LO1) as in the first LOCK request.

The question is what does the server do with this second LOCK request.
since the second LOCK request is using an "established" lock_owner and
potentially specifying a new lock_seqid.

For this case, I am coding our server to return NFS4ERR_BAD_SEQID
therefore forcing the client to appropriately track its use of a
lock_owner/file association.

Comments?

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 12 Dec 2002 15:18:37 -0600

I need to point out that the client under error conditions does have a
valid reason to send a LOCK(new_lock_owner) request where one was sent
previously.

This is the case where the initial LOCK request received errors like:
NFS4ERR_DENIED, NFS4ERR_GRACE and the client is going to retransmit
the request with a new open_owner sequence id, etc.

In this case, the server will need to accept this request.  So the
qualification on my scenario below is that the LOCK request succeeded
with NFS4_OK and then subsequent LOCK(new_lock_owner) with the
existing lock_owner/file pair is invalid.

-- 
Spencer