Subject: OPEN4_RESULT_MLOCK

From: "Ronald E Bretschneider" <[email-masked]>
Date: Tue, 6 Aug 2002 16:57:53 -0700

In the July 2002 version of the NFS V4 Protocol, page 150, last
paragraph, it discusses the rflags returned by a successful OPEN.  It
states that the OPEN4_RESULT_MLOCK indicates to the caller that mandatory
locking is in effect for this file.  This is confusing.  We thought locking
was always mandatory in V4.  When does the server set this flag and when
does it not set it?

 thanks,
 Ron

---

From: Mike Eisler <[email-masked]>
Date: Wed, 07 Aug 2002 08:08:25 -0700

> was always mandatory in V4.  When does the server set this flag and when

I had made the same observation to Dave Noveck and Spencer
here at the NFSv4 bakeoff when your message arrived. _MLOCK
isn't very useful since in some operating environnments,
a file could have mandatory or advisory locking toggled at
will. The i-d does mention advisory and mandatory locking
in several places though.

Very early drafts of the specification assumed whole
file mandatory locking always on but by the time RFC3010
was published, the WG reached consensus on supporting
byte range (record) mandatory and advisory models that
allowed clients and servers the choice in forcing the
use of record locking and whether it is mandatory and
advisory. Unfortunately, some of that that early text
survived, such as in the READ operation description.

In reading an i-d from the weekend, I actually gathered the
opposite impression from yours, at least with respect to
UNIX environments. It seemed to me that the specification
was very lean on describing how UNIX mandatory locking
would work. Such as no discussion of the mandatory lock
bit in the mode attribute, and no discussion of what the
client should do when it it gets NFS4ERR_LOCKED from the
server (the answer is per UNIX mandatory locking semantics,
the client needs to grab the lock explicitly first).

After talking with Dave N and Spencer, it was clear
that they believed the i-d overall implies that
mandatory locking for Windows and UNIX is part of the
specification. Last night (this morning really) I gave
Spencer some text that should clarify it. I'll read it
again, and probably tweak it more, but I expect Spencer
will post a new i-d at nfsv4.org when he wakes up today.

	-mre

p.s. _MLOCK will be history in the next i-d. Clients will
divine that they need to get record locks when
they get back the NFS4ERR_LOCKED error.