Re: NFSv4.2 server replies to Copy with length == 0
Rick Macklem <[email protected]>
| Newsgroups | gmane.ietf.nfsv4 |
|---|---|
| Message-ID | <YTBPR01MB28453BA8ADD6E982F59BDACCDD690@YTBPR01MB2845.CANPRD01.PROD.OUTLOOK.COM> |
Frank Filz wrote: >> (That's why I've asked other implementors to put their hands up and, sofar, >> there hasn't been any hands up. I thought Ganesha was working on NFSv4.2, but >> no one has posted on [email protected] about it.) > >Sorry no one from Ganesha has raised their hand. I have been watching this >discussion, but we have limited 4.2 support. As far as I know, no one has >implemented server side copy on Ganesha. Along with the Copy ones, there is the problem I brought up a while ago w.r.t Seek. I recall Ganesha did encounter that one? The case is: Seek Arguments: sa_offset: <file_size> sa_what: NFS4_CONTENT_DATA Reply that Linux client expects: (A) NFS4ERR_INVAL whereas the RFC seems to indicate (B) NFS_OK sr_eof: true sr_offset: <file_size> Which of these does you current code implement? (If it is (B), the code I posted will break when run on a Linux client against your server.) Has this code shipped to users yet? Thanks for the input, rick Frank _______________________________________________ nfsv4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nfsv4