> On Nov 30, 2017, at 8:25 AM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote:
>
> 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.
Right, but my issue is that I need to have my server let EISDIR through in this
case.
I’m inclined to file an errata, I’ll just have to get to it. :-)
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
