On Wed, Oct 16, 2019 at 07:53:45PM +0000, Kornievskaia, Olga wrote: > On 10/16/19, 11:58 AM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > 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. > > Sigh, well, I don’t know if we should consider adding the check to the > NFS server to be NFS spec compliant. VFS layer didn't want the check > and instead the preference has been to keep read() semantics of > returning a short read (when the len was beyond the end of the file or > if the source) to something beyond the end of the file. I'm inclined to think the spec's just wrong. And how else could a client possibly interpret a 0 return? > On the client if VFS did read of len=0 then VFS itself we return 0, > thus this doesn't protect against other clients sending an NFS copy > with len=0. And in NFS, receiving copy with len=0 means copy to the > end of the file. It's not implemented for any "intra" or "inter" code. A call with len=0 sounds like a different case. --b.
