From: Boris Z. (boris@conley.com)
Date: 08/20/98-11:59:37 AM Z
Message-ID: <01BDCC21.3E477760.boris@conley.com> From: "Boris Z." <boris@conley.com> Subject: RE: NFSv4: Identifying users & groups (Fwd) Date: Thu, 20 Aug 1998 09:59:37 -0700 On Wednesday, August 19, 1998 2:03 PM, Brent Callaghan [SMTP:Brent.Callaghan@eng.Sun.COM] wrote: > > > Only two more things . Should PC clients (or any other clients as well) pay > > attention to RWE bits for groups in attribute's mode? > > All clients should use ACCESS rather than permission bits in > determining the type of file access permitted. Otherwise, > the bits should be used for reporting only. > > Of course, there will always be attributes that have no > meaning to a client or cannot be reported through the API's on > a client. A good example is the DOS/Windows "archive" > bit that has no equivalent in Unix. > I agree with this. However, we should recognize (as we do with user names, ACCESS types, time, etc.) that there are three components <server>,<protocol>,<client>. Each of them may have their own file system semantics. Protocol's semantics should be convenient enough to address needs of both a client and a server. In all places were we deal with meta-data I'd like to see servers make efforts to map their semantics into the protocol semantics. In all such places I'd allow optionally attach server side native elements. This will greatly help homogeneous client-server combinations. Particularly, I think that after introduction of ACCESS we can remove notion of a group from the protocol semantics of file attributes (even in Unix world that was unbalanced - user could belong to many groups, but file could not). From other point I'd like to find a place for following NT attributes: HIDDEN, SYSTEM, ARCHIVE, TEMPORARY, COMPRESSED. Unix servers may set all of them to 0 and Unix clients may ignore them if they wish. Boris
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:12 AM Z CST