Subject: [nfsv4] openowner vs lockowner stateids

From: [email-masked]
Date: Mon, 5 Jan 2004 15:22:00 -0500 (EST)

[good stuff snipped]
> It is valid (i.e. not an error) to pass the open stateid even 
> if your process has done locking but in that case, your 
> request will be treated as issued by an anonymous lockowner,
> i.e. some unknown process that has done no byte-range
> locking for the file in question.

Does the RFC say this? My server checks for an "owner" match for
conflicting locks (for the I/O Ops) by comparing the "owner" bytes
for a match. (As such, the Openowner with the same "owner" opaque
bytes as the lockowner would not be anonymous, assuming the stateid
used is the one for the Openowner.)

Does this sound ok? (Or are openowner "owner" and lockowner "owner"
also to be considered distinct, even if the "owner" opaque bytes are
the same?)

Thanks for any info, rick
ps: To the original poster. The best source of information on this are
	Dave's emails. Look for ones addressed to me in the mailing list
	archive, about a year ago?

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 5 Jan 2004 16:05:49 -0600

Dave's interpretation is correct and is likely not explicitly stated
in the RFC (yet another deficiency in this area).

An openowner should be treated as an "anonymous" openowner
when it comes to file lock comparisons.  The reason is that
the openowner does not correctly communicate the locking state
for the file and therefore does not correctly "fence" access for
operations like READ/WRITE.

Spencer