Re: NFSv4.2 server replies to Copy with length == 0

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Oct 16, 2019 at 07:53:45PM +0000, Kornievskaia, Olga wrote:
> On 10/16/19, 11:58 AM, "J. Bruce Fields" <bfields@fieldses.org> 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.