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@xxxxxxxxxxxx> wrote: > >>> On Thu, Mar 05, 2009 at 12:09:40PM +0200, Benny Halevy wrote: > >>>> On Mar. 05, 2009, 11:32 +0200, Ni Wenjuan <niwj@xxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
