[patch]fix return value of not support compound operationOP_PUTPUBFH

[Tom Talpey]

At 09:33 AM 3/9/2009, Noveck, Dave wrote:
>> That shouldn't matter. 
>
>Why not?  The spec lists the valid errors for each op for a reason.
>
>> The meaning of that error is "Operation is not
>> supported.". If your server hasn't implemented that operation, then
>> NFS4ERR_NOTSUPP is the only valid return. Are you saying that PUTPUBFH
>> is mandatory to implement?

BTW, it is. Page 392 of minorversion 1:


   | PUTFH                | REQ        |              | Section 18.19  |
   | PUTPUBFH             | REQ        |              | Section 18.20  |
   | PUTROOTFH            | REQ        |              | Section 18.21  |


and similar text in 3530.
>Exactly.  Listing ops as able to report NFS4ERR_NOTSUPP is the way the
>spec indicates that they are optional to implement or that there is some
>particular feature that may be requested that is optional to implement.

True, but NOTSUPP isn't an option for mandatory ops.

>> Why not just let PUTROOTFH die the horrid death it deserves? 
>
>Because the working group put in RFC3530.  Given that, there would have
>to be an awfully strong reason (and maybe a new RFC) to delete it.
>What's the problem with it?

I don't think Trond is advocating its removal. But I agree, it has always
appeared to me rather useless.

>We also had the opportunity to delete in in v4.1.  We deleted a number
>of operations from v4.0 but I didn't hear any request to delete
>PUTPUBFH, thoughout the whole of the v4.1 discussion and certainly there
>were none during group last call.  Also it isn't listed in
>draft-ietf-nfsv4-minorversion1-29.txt as able to return NFS4ERR_NOTSUPP.

PUTROOTFH not PUTPUBFH. But in any case, it can't be removed without
first downgrading it to optional for at least one minor version.

Tom.