From: Spencer Shepler (spencer.shepler@sun.com)
Date: 03/02/04-10:56:16 AM Z
Message-Id: <853EB9CB-6C6A-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 10:56:16 -0600 On Mar 2, 2004, at 10:43 AM, Stevan Steve Allen wrote: > > >On Mar 3, Spencer wrote: > > > >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. > > From my small world, there seems to be a strong urge to return > something for owner/owner_group in the event of an -ls/dir command. > Either the server internal string (possibly appending > @server_domain), or the server assigned UID/GID in string format. > > Sorry to say I'm not familiar with the clients view of this topic or > the reason to map such strings. At least the Solaris client (and most unix derivatives) will take the owner/group strings and map them to the uid/gid integer values that are present in the various attribute structures in APIs like stat(). Therefore, the client will take your server's owner/group string and attempt to map and it will likely end up mapping to "nobody" because it is unable to map it appropriately. There will be a total loss of information; given that you know that your internal strings don't map to even the uid/gid (I am assuming this) it doesn't seem worthwhile in providing the info. If there were clients that just passed the owner/group strings back through their local APIs unmapped then there may be some value but I don't know of such clients at this point. 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:20 AM Z CST