Subject: RE: [nfsv4] Getting to closure to NFS4ERR_FILE_OPEN

From: "Peter Varga" <[email-masked]>
Date: Mon, 17 Dec 2007 11:36:12 -0500

> Although there has not been any disagreement expressed, I am not sure
> there is consensus as to Peter Varga's idea that FILE_OPEN is intended
> to be used when non-NFSv4 open's prevent a remove/rename/link.  The
> reason that this issue is important for the spec is that if that is
so,
> then servers won't ever have to recall delegations to ascertain
whether
> such opens exists.  So the question remains whether servers may choose
> to exclude such operation because of the presence NFSv4 opens other
> than due to DENY-{WRITE,BOTH} opens on the target of a REMOVE or a
> renamed-over file or whether the spec should limit FILE_OPEN to that
> specific case plus any cases necessary for a multi-protocol server to
> be compliant with requirements of other protocols.

The server may have other OS-specific reasons for preventing
rename/remove/link when a file is open at all, regardless of the sharing
mode bits. For instance, Windows will not allow a rename-over if the
target is open at all. I thought your proposed addition provided
sufficient explanation:

"   A server may disallow this operation when the corresponding file
   is open, or open with particular modes specified.  When the operation
   is disallowed on this basis, the error NFS4ERR_FILE_OPEN is
returned."

> The second issue has to do with the semantics mentioned in REMOVE (and
> by implication I think it applies to files removed due to rename-over)
> regarding NFSv4 opens that are DENY-{WRITE,BOTH}.  Peter has given
some
> good arguments about why this was a poor choice made by RFC3530, but
my
> feeling is that they are not so strong as to justify changing things
at
> this late date.  I'd like to hear other opinions on this issue,
though.

One vote from me for removing it :)

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 17 Dec 2007 18:02:03 -0600

> target is open at all. I thought your proposed addition provided

The OS-specific reasons are the most relevant.  As you note,
there is an existence proof of an environment that would disallow
the remove and the server needs a method of responding with
a meaningful error.

> One vote from me for removing it :)

That language has not caused a problem to date and late changes
bother me -- insufficient time to poll existing implementations, etc.

The language should stay IMO.

Spencer