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

Returning to the original question.  Do we need any updates
to the rfc3530bis (and symmetrical an errata filed for 5661)?

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of
> J. Bruce Fields
> Sent: Thursday, August 18, 2011 8:19 AM
> To: Trond Myklebust
> Cc: nfsv4@ietf.org
> Subject: Re: [nfsv4] Last call for RFC3530bis-13 (ends on Sept 2nd)
> 
> 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.
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4