On Thu, Nov 30, 2017 at 01:13:30AM +0000, Thomas Haynes wrote:
> Bruce,
>
> [root@client1-ci-291117203803930 nfs4.1]# ./testserver.py 172.29.53.145:/ --verbose --outfile=/tmp/pynfs4.1.out --minorversion=2 --maketree RNM14
> Could not find gssapi module, proceeding without
> INFO :rpc.poll:got connection from ('127.0.0.1', 55390), assigned to fd=5
> INFO :rpc.thread:Called connect(('172.29.53.145', 2049))
> INFO :rpc.poll:Adding 6 generated by another thread
> INFO :test.env:Created client to 172.29.53.145, 2049
> INFO :test.env:Called do_readdir()
> INFO :test.env:do_readdir() = []
> RNM14 st_rename.testFileToDir : RUNNING
> RNM14 st_rename.testFileToDir : FAILURE
> RENAME file into existing dir should return
> NFS4ERR_EXIST or NFS4ERR_ISDIR, instead got
> NFS4ERR_SERVERFAULT
> INFO :test.env:Called do_readdir()
> INFO :test.env:do_readdir() = [entry4(cookie=418L, name='RNM14_1512003093', attrs={})]
> INFO :test.env:Called do_readdir()
> INFO :test.env:do_readdir() = [entry4(cookie=419L, name='dir', attrs={}), entry4(cookie=420L, name='file', attrs={})]
> **************************************************
> RNM14 st_rename.testFileToDir : FAILURE
> RENAME file into existing dir should return
> NFS4ERR_EXIST or NFS4ERR_ISDIR, instead got
> NFS4ERR_SERVERFAULT
> **************************************************
> Command line asked for 1 of 280 tests
> Of those: 0 Skipped, 1 Failed, 0 Warned, 0 Passed
>
> Yet according to RFC 5661, Section 15.2 (table 6), NFS4ERR_ISDIR
> is not an allowed error code for RENAME.
>
> According to POSIX rename() it is an allowed error code. I believe
> the assumption is that the client should catch this case first?
>
> Anyway, does the knfsd return NFS4ERR_ISDIR in this test case?
I just checked--yes. Looking at git history, I find commit
2a6cf944c2f8, which says
nfsd4: don't remap EISDIR errors in rename
We're going out of our way here to remap an error to make rfc 3530
happy--but the rfc itself (nor rfc 1813, which has similar language)
gives no justification. And disagrees with local filesystem behavior,
with Linux and posix man pages, and knfsd's implemented behavior for v2
and v3.
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 honestly I think the rfc's are just buggy here--or in any case it
doesn't see worth the trouble to remap this error.
--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
