Subject: [nfsv4] Is OPEN mandatory before a LOCK on the file?

From: Natesh Kedlaya <[email-masked]>
Date: Mon, 13 Jul 2009 14:05:01 -0700 (PDT)

Hello Experts.
  I have read the RFC3530 many times trying to understand the relationship between the OPEN and LOCK.
  One question that I could not answer till now "Is OPEN mandatory before a LOCK operation on the file?"
  I appreciate if someone clarify it.

Thanks,
Natesh

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 15 Jul 2009 13:34:58 -0400

>   I appreciate if someone clarify it.

Yes.  The LOCK operation requires either an open stateid or a lock
stateid.  The lock stateid can only come from a previous lock operation.
So at some point you had to have an open statied.  And the only way to
get one is from an open.

--b.

---

From: Rick Macklem <[email-masked]>
Date: Wed, 15 Jul 2009 15:24:10 -0400 (EDT)

>  I appreciate if someone clarify it.
The short answer is "yes", because you need to do the 
"open_to_lock_owner4" case the first time, and that requires an 
open_stateid.

Then you run into the really cool part (which makes a server's 
implementation much more involved) in the second para. of
DESCRIPTION (for CLOSE):
 	...SHOULD release all locks...MUST return failure if
 	any locks would exist after the CLOSE.
And which locks are these? Well, the ones "associated" with
the open_stateid by the "open_to_lock_owner4" done above.
(Therefore, the server must keep track of which locks are
"associated" with which open stateids, as above. And that also
implies that there might multiple "instances" of the same lock_owner4,
but related to different open_stateids.

Without that one little para. in the DESCRIPTION for CLOSE, the
handling of byte range locking could have been much simpler.

I haven't read the 4.2 drafts much, but I believe they explain this
stuff much better than RFC3530.

rick, who believes the above is correct after being involved in
several debates about it some years ago.