Subject: RE: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Jul 2006 14:29:42 -0400

I think in all the cases you mentioned, we a have situation in 
which the set of attributes you ask for can effect whether you 
get an error or not.  I'm not aware of any case in which you 
will get different values for a single attribute (no error in 
either case) based on whether you are asking for a different 
attribute.  Other than things like asking for an attribute
that doesn't exist will cause an error to be set in rdattr_error,
but that is part of the function of rdattr_error.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Friday, July 14, 2006 2:23 PM
To: [email-masked]
Cc: Sam Falkner; Pawlowski, Brian; Spencer Shepler;
[email-masked]
Subject: Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction /
mask,draft-ietf-nfsv4-acls-00 not ready

On Fri, Jul 14, 2006 at 01:59:30PM -0400, J. Bruce Fields wrote:
> For a client that doesn't support the new attributes, a server can
apply
> the mask attributes to the ACL before returning it.  I suppose a
> multi-protocol server would do the same for CIFS clients.

By the way, the proposed protocol behavior here is odd:  the server
returns a different ACL depending on whether the client requested any of
the new mask attributes in the same GETATTR.

But I suppose there are other cases (rdattr_error, maybe some migration
cases??) where what we return can depend in strange ways on which
attributes were requested, so maybe it's not totally without precedent?

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 14 Jul 2006 14:32:44 -0400

On Fri, Jul 14, 2006 at 02:29:42PM -0400, Noveck, Dave wrote:
> I'm not aware of any case in which you 
> attribute.

Yeah, OK.  So, like I say, it's an odd thing to do.  I haven't managed
to come up with any fundamental reason why it won't work, though.

--b.