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

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

On Thu, Aug 18, 2011 at 11:13:02AM -0400, Trond Myklebust wrote:
> On Thu, 2011-08-18 at 11:07 -0400, J. Bruce Fields wrote: 
> > 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.
> 
> I can live with those returning NFS4ERR_INVAL. Those are all cases where
> the error applies to an invalid object which was passed in the form of a
> filehandle. IOW: the client can and should know better.

Yeah, agreed.

(In fact, INVAL may be the preferred error--but as long as the operation
fails in these cases I think any reasonable error is fine.  E.g. the
linux server is currently going out of its way to map lower-level
symlink errors to INVAL in the above cases, and I don't see the point,
so I'm inclined to just delete that extra code.)

> > (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?)
> 
> Are they? They seem correct to me. Remember that RFCs list the page
> number at the bottom of the page and not the top.

Doh!

--b.