On Wed, Oct 16, 2019 at 06:22:42AM +0000, Rick Macklem wrote: > 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. I've never understood that INVAL requirement. But I know it's been discussed before, maybe there was some justification for it that I've forgotten. --b. > > 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
