[nfsv4] Asking for details about OPEN_DOWNGRADE

[Mike Mackovitch]

On Fri, Jun 13, 2008 at 04:34:49PM -0400, J. Bruce Fields wrote:
> On Fri, Jun 13, 2008 at 01:29:55PM -0700, Mike Mackovitch wrote:
> > On Fri, Jun 13, 2008 at 02:52:51PM -0400, Trond Myklebust wrote:
> > > How should it be 'fixed' in your opinion?
> > 
> > By explicitly specifying that the behavior described above should not
> > be allowed.  It is clear that the spec is NOT clear about that....
> > otherwise, the spec wouldn't be getting "misinterpreted" by many people.
> > 
> > The text in the OPEN and OPEN_DOWNGRADE descriptions, as well as "Open
> > Upgrade and Downgrade" sections, leads me (and others) to believe that
> > the server only keeps one "OR"ed-together status for that owner and
> > thus sending multiple, redundant OPEN requests (for that owner) was
> > unnecessary.
> 
> The text of rfc 3530 ("exactly equal to the union of...") doesn't seem
> ambiguous to me.

Well, the whole text there is:

> The share_access and share_deny bits specified in this operation
> replace the current ones for the specified open file.  The
> share_access and share_deny bits specified must be exactly equal to
> the union of the share_access and share_deny bits specified for some
> subset of the OPENs in effect for current openowner on the current
> file.

And, to me at least, the qualifier "subset of the OPENs in effect"
doesn't clearly say "the subset of the OPEN ops sent to the server".

So, if an implementation didn't send an OPEN op to the server because
that OPEN op wasn't going to change/upgrade the open state for that
owner, then the server doesn't know about that open even though it is
"in effect".

--macko