Subject: Locking question...

From: Venkatesh Nayak <[email-masked]>
Date: Mon, 19 Jun 2000 15:34:12 -0700

Hi,

  This may be a stupid question but I am kinda' new to NFSv4. I looked
 briefly at the archive and the rfc but could not figure this out.

 o How is NFS v4 going to guarantee mandatory file locking in an environment
   where there are both NFS v4/v3 clients ?. To be more specific, can a 
   v3 client using NLM (or not using) come in and read/write a file for which
   another v4 client has a mandatory "deny all" lock ?.

 Please cc. me on your response as I just subscribed to this list and I may
 name may not yet be added to the list.

 Venkatesh

---

From: David Robinson <[email-masked]>
Date: Mon, 19 Jun 2000 16:03:04 -0700 (PDT)

>    another v4 client has a mandatory "deny all" lock ?.

This is not a stupid question.  However, it is not a protocol issue
but an implementation issue.

One possible implementation is to merge the share functionality of NLM
and V4, so that they interact completely. The default of Unix clients
would typically be Read or Read/Write with Deny None.  So for
the general case there would not be a perceived difference.  With
a Windows client, the already are using NLM for create the appropriate
shares and honor it amongst other Windows clients, but Unix clients
are typically kept seperate.  With V4, a Unix client (either V3 or V4)
might have an open() rejected that it previously would not have.

More interesting problems are if a V3 client has obtained a file handle
without using NLM and does an open, the V3 server cannot know if
the getattr (V2) or access (V3) is really an open or not.  Then at
some later time a V4 client does a Deny All, what happens to the
existing open?  Should continue to work?  Fail? Fail only if a
byte range lock is obtained that conflicts?

There are many other similar examples. Another would be SVR[34] manditory
locking and its interactions.

This whole area is one where it is not appropriate to detail out the
solutions in the protocol spec, but a very good candidate for
a best practices informational RFC.

	-David