Re: [nfsv4] Last call for RFC3530bis-13 (ends on Sept 2nd)

["J. Bruce Fields" <[e-mail]>]

On Wed, Aug 17, 2011 at 01:30:28PM -0500, Thomas Haynes wrote:
> 
> On Aug 17, 2011, at 8:05 AM, Trond Myklebust wrote:
> 
> > 
> > Does it contain any advice on the OPEN return value when applied to a
> > file that is not a regular file, symlink or directory? I'll be back in
> > active duty and able to check for myself tomorrow, but I thought I'd
> > draw it to your attention now.
> > 
> 
> I assume you are speaking with respect to the recent thread:
> 
> Re: [nfsv4] open() of device special files
> 
> And the answer would be no, we made no changes from 3530
> there.
> 
> You want to add text to the effect to return NFS4ERR_SYMLINK
> on an OPEN of an incorrect type?

Also not a spec issue unless this goes unfixed in our implementations,
but note rfc 5661 requires NFS4ERR_WRONG_TYPE in the case of OPEN of a
device (p. 455 in the OPEN implementation section, "If the component is
neither of those but not an ordinary file, the error NFS4ERR_WRONG_TYPE
is returned.")

One other 3530bis question:

I'm trying to decide where else the server could return NFS4ERR_SYMLINK.
3530bis says COMMIT, LOOKUP, LOOKUPP, OPEN, READ, WRITE.

I wonder about:

	CLOSE, OPEN_CONFIRM, LOCK, LOCKU, LOCKT: as with READ, WRITE,
	and COMMIT, these cases where the client should have known
	better, and we may as well allow (but not require)
	NFS4ERR_SYMLINK, as we do NFS4ERR_ISDIR.  (Also NFS4ERR_SYMLINK
	is on the error lists for some of these in rfc 5661).

	CREATE, READDIR, REMOVE, RENAME, SECINFO, possibly some others:
	currently require NFS4ERR_NOTDIR.  I wonder if NFS4ERR_SYMLINK
	should also be allowed.  I guess these are also buggy-client
	cases, so I think it's safely left up to the implementation
	whether to return INVAL, NOTDIR, or SYMLINK.

(And, a really nitty nit: why are the page numbers in the table of
contents at

	http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-13

off by one?)

--b.