Re: NFSv4.2 server replies to Copy with length == 0
"J. Bruce Fields" <[email protected]>
| Newsgroups | gmane.ietf.nfsv4,gmane.linux.nfs |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Oct 17, 2019 at 02:16:36AM +0000, Rick Macklem wrote: > I have now found two cases where the Linux NFSv4.2 server does not > conform to RFC-7862. One is as above and the other is a reply to Seek > of NFS4ERR_NXIO when the sa_offset argument == file_size (instead of > replying NFS_OK along with sr_eof == true). Huh. Looks like that's documented behavior of Linux's seek. (See the ERRORS section of the lseek(2) man page.) Looks like Solaris also returns -ENXIO in this case: https://docs.oracle.com/cd/E26502_01/html/E29032/lseek-2.html And freebsd too: https://www.freebsd.org/cgi/man.cgi?query=lseek&sektion=2 I wonder where that spec language came from? Our NFS server could translate an -ENXIO return into 0 and sr_eof == true easily enough, assuming -ENXIO is really only ever returned in that case. I haven't tested, but from a quick check of the Linux client code I think that would require a matching fix on the client side to translate sr_eof == 0 *back* to ENXIO. I don't know if it's worth it. --b. _______________________________________________ nfsv4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nfsv4