Re: [nfsv4] one umask-02 question

On Thu, Dec 01, 2016 at 04:49:18PM -0500, David Noveck wrote:
> > 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)

It has other uses too; e.g. see rfc5661 6.2.5, which is very similar:

	If the mode and mode_set_masked attributes are both specified in
	the same SETATTR, the server MUST also return NFS4ERR_INVAL.

I think INVAL would be fine.

> 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.

I don't have any strong reason to care whether we require mode to be
ignored (or, equivalently, applied first), or we require INVAL be
returned.  Andreas, am I missing anything?

--b.

> 
> > (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
> >

> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4