It seems that the Copy reply with wr_count == 0 occurs when the client sends a Copy request with ca_src_offset beyond EOF in the input file. (It happened because I was testing an old/broken version of my client, but I can reproduce it, if you need a bugfix to be tested. I don't know if the case of ca_src_offset+ca_count beyond EOF behaves the same?) --> The RFC seems to require a reply of NFS4ERR_INVAL for this case. rick ________________________________________ From: linux-nfs-owner@xxxxxxxxxxxxxxx <linux-nfs-owner@xxxxxxxxxxxxxxx> on behalf of Rick Macklem <rmacklem@xxxxxxxxxxx> Sent: Tuesday, October 15, 2019 10:50 PM To: linux-nfs@xxxxxxxxxxxxxxx Subject: NFSv4.2 server replies to Copy with length == 0 During interop testing (FreeBSD client->Linux server) of NFSv4.2, my client got into a loop. It was because the reply to Copy was NFS_OK, but the length in the reply is 0. (I'll fix the client to fail for this case so it doesn't loop, but...) The server is Fedora 30 (5.2.18-200 kernel version). It you think this might be fixed in a newer kernel or you'd like me to do something with it to get more info, just let me know. I've attached a snippet of the packet trace. (If the list strips it off, just email me and I'll send it to you.) rick
