Re: NFS4ERR_SYMLINK error

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Mar 13, 2009 at 04:13:39PM +0800, Yang Hongyang wrote:
> J. Bruce Fields wrote:
> > On Sat, Mar 07, 2009 at 08:59:16PM +0200, Benny Halevy wrote:
> >> On Mar. 06, 2009, 23:32 +0200, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> >>> On Thu, Mar 05, 2009 at 12:09:40PM +0200, Benny Halevy wrote:
> >>>> On Mar. 05, 2009, 11:32 +0200, Ni Wenjuan <niwj@cn.fujitsu.com> wrote:
> >>>>> the result of newpynfs test case of  LINK4a .  if you link with target directoty
> >>>>>  is a symbole file,it should get NFS4ERR_NOTDIR ,instead got NFS4ERR_SYMLINK.
> >>>>>
> >>>>> THE LINK operation  don't list NFS4ERR_SYMLINK as valid errors in the spec. But
> >>>>> NFS4ERR_SYMLINK seems like a reasonable error.  Is this an oversight
> >>>>> in the spec, or something we need to fix?
> >>>> Although NFSv4.1 adds NFS4ERR_SYMLINK to LINK's allowed errors list
> >>>> (and this might be an indication for it being an oversight in rfc3530),
> >>> The error lists in rfc3530 are known to be incomplete in some cases, so
> >>> before adding an exception like this I'd like something more.  (E.g.:
> >>> does this cause any client or application to fail?  Is there some
> >>> logical reason notdir is a more useful error than symlink?)
> >> FWIW, the linux nfs client translates NFS4ERR_SYMLINK to -ELOOP
> >> which is awkward and less descriptive to the app / user than
> >> -ENOTDIR.
> > 
> > Hm, OK.  If we fix this will -ELOOP then become reasonable for our
> > remaining NFS4ERR_SYMLINK returns?
> 
> Bruce,Do you think we do not need to fix this?

Given the spec and the client behavior, I guess it sounds reasonable to
fix it, if Benny could just resend with a new comment and signed-off-by.

--b.