From: Spencer Shepler (spencer.shepler@sun.com)
Date: 03/02/04-01:05:20 AM Z
Message-Id: <F7E157C0-6C17-11D8-A9CF-000A95DBCB70@sun.com> From: Spencer Shepler <spencer.shepler@sun.com> Subject: Re: [nfsv4] (no subject) - Owner Group attr strings. Date: Tue, 2 Mar 2004 01:05:20 -0600 On Feb 27, 2004, at 6:11 PM, Stevan Steve Allen wrote: > > >>Do you mean “OWNER@” and “GROUP@” are not supported by server or > something else? > >>Why would domain name be unknown? > >>- Sergey > > I am speaking of owner and owner_group attributes 36 & 37 not being > supported by the server for SETATTR. The protocol states if the > server supports owner & owner_group on SETATTR, the server promises to > return the exact same string on a subsequent GETATTR. > > If a server can not support the requirement for setting and returning > the same owner & owner_group attributes, it seems it must turn off > support in the server supp_attr mask, which would also affect getattr > and readdir not returning the strings. The server turning owner & > owner_group "on" would suggest the server supports a SETATTR of owner > and owner_group. > > Does anyone expect otherwise? ...such as... a server which says it > supports owner/group (attr mask) and returns internal strings as > owner/group and does not allow setting these values (using an error > code for setattr). ? e.g. Is there a benefit or need to obtain the > servers internal strings vs. nothing? I don't see any value for a server to return internal string identifiers for owner/group. The client will likely not have any reasonable means of mapping them to its own APIs for use by the application or end user. Therefore, the server should not return the attributes and let the client default to some user/group understood by the local environment as "not useful". Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:19 AM Z CST