Subject: [nfsv4] Another rename question

From: Frank S Filz <[email-masked]>
Date: Tue, 16 Apr 2013 17:10:59 -0700

Both RFC 1813 and 3530 specify:

If the directory, to.dir, already contains an entry with
the name, to.name, the source object must be compatible
with the target: either both are non-directories or both
are directories and the target must be empty. If
compatible, the existing target is removed before the
rename occurs. If they are not compatible or if the target
is a directory but not empty, the server should return the
error, NFS3ERR_EXIST.

In contrast, man 2 rename indiates the following errors will result:

EISDIR newpath  is  an  existing directory, but oldpath is not a
directtory.

ENOTDIR A component used as a directory in oldpath or newpath is not, in
fact,  a  directory.   Or,  oldpath  is a directory, and newpath exists but
is not a directory.

EEXIST newpath is a non-empty  directory,  that  is,  contains  entries
other than "." and "..".

I suppose my server should hew to the RFC, but it would be nice to just
translate the return code from rename()...

On the other hand, would a client really get bent out of shape to get an
unexpected NFS3ERR_ISDIR or NFS4ERR_ISDIR from rename?

Thanks

Frank

---

From: Malahal Naineni <[email-masked]>
Date: Wed, 17 Apr 2013 06:25:44 -0500

Frank S Filz [[email-masked]] wrote:
>    fact,  a  directory.   Or,  oldpath  is a directory, and newpath exists
>    but is not a directory.
> 

knfsd NFSv4 seems to follow the spec. See nfsd4_rename()

>    unexpected NFS3ERR_ISDIR or NFS4ERR_ISDIR from rename?

I don't think so, as NFSv3 seems to return (not confirmed, just code
reading) just the rename() status.

Regards, Malahal.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Apr 2013 15:22:06 -0400

> knfsd NFSv4 seems to follow the spec. See nfsd4_rename()

Yeah, it goes out of its way to remap that error in the v4 case.  But
the only justification for that code is "the spec said so"--and the spec
itself gives no justification.  And appears to disagree with both the
Linux and posix man pages, and with knfsd's implemented (if not the
rfc-1813-described) behavior.

And the documented behavior seems better, in that it gives a little more
information--you could implement the 3530 behavior using the posix
behavior, but not the other way around.

Also, the Linux client makes no attempt to remap this error in the v4
case, so it can end up just returning EEXIST to the application in a
case where it should return EISDIR.

So I honestly think this is just a spec bug.  I'll fix knfsd if there
are no objections.

--b.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Frank S Filz <[email-masked]>
Date: Tue, 30 Apr 2013 16:03:50 -0700

"J. Bruce Fields" <[email-masked]> wrote on 04/30/2013 12:22:06 PM:
> > >    ENOTDIR A component used as a directory in oldpath or newpathis
not, in
> So I honestly think this is just a spec bug.  I'll fix knfsd if there

It also looks like it's possible to get ENOTEMPTY in some circumstances. I
assume that should be left alone also (translated to NFS4ERR_NOTEMPTY).

Hmm, having coded Ganesha to follow the RFCs, I will now code it back to
leave these errors alone...

Frank