[nfsv4] Asking for details about OPEN_DOWNGRADE

[J. Bruce Fields]

On Fri, Jun 13, 2008 at 01:50:34PM -0700, Mike Mackovitch wrote:
> 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".

That's "OPEN", not "open", and can only refer to the on-the-wire op, not
to whatever notion the client vfs has of an open file descriptor (which
isn't really the protocol spec's business anyway).

Do you find the 4.1 language clearer?

--b.

> 
> 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