Re: [nfsv4] one umask-02 question

> I don't understand why the server doesn't return an error in
> this case.

I'm not sure either.  Part of the problem may be that it isn't clear what
error to return.  INVAL is ised to inicate an unknown attribute or one used
with the wrong operation (get vs. set) so maybe we would need
NFS4ERR_BADATTRCOMB.

> Silently throwing stuff away makes me nervous.

I can see how that statement would raise red flags.

On the other hand, suppose there were no such statement and a create
contained both mode and umask.  Allowing these to be applied in whatever
order the server chooses is a recipe for non-interoperable
implementations.  The natural thing is to say that if both of these
attributes are present, umask is (MUST be) applied  last, in which case
mode would have no effect.  The effect is the same as saying it MUST be
ignored, but in this case, it is not a directive but a consequence of the
fact that anything it says will be overwritten as part of creating the file.

> (If this was already discussed, feel free to just give me a
> pointer to the discussion.)

D

On Thu, Dec 1, 2016 at 3:10 PM, Mike Kupfer <mike.kupfer@oracle.com> wrote:

> Section 3 has
>
> >    The server MUST ignore any mode attribute set in the same operation
> >    as mode_umask.
>
> I don't understand why the server doesn't return an error in this case.
> Silently throwing stuff away makes me nervous.  (If this was already
> discussed, feel free to just give me a pointer to the discussion.)
>
> thanks,
> mike
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>