From: Mike Eisler (mre@eng.sun.com)
Date: 06/07/99-01:45:30 PM Z
Date: Mon, 7 Jun 1999 11:45:30 -0700 (PDT) From: Mike Eisler <mre@eng.sun.com> Subject: Re: Named (extended) attributes vs. subfiles Message-ID: <Roam.SIMC.2.0.6.928781130.3179.mre@eng.sun.com> > READ/WRITE may not make sense for ACLs. ACLs have structure. > So do directories. How would be contemplate implementing > READDIR via NFS_READ? How about CREATE via NFS_WRITE? > We wouldn't contemplate such. That's the trickiness I mean. > Distinct NFS operations which are applicable to a variety > of ACL models/designs/implementations are required. > Trying to do this via READ/WRITE would likely lead to > the chaos you're concerned about. READ/WRITE should be > soley for opaque content. My interpretation of the current NFS V4 specifcation is that "extended" attributes (which Io think the document should label as "named") are always opaque to the server. The attributed in the Mandatory and Recommended lsit are never opaque to the server. I'm not sure if you are proposing that named attributees be partitioned into opaque and non-opaque. If so, I don't see the need for the complexity. My interpretation of the specification is that OPENATTR, and subsequent operations like READ, WRITE, would apply only to named attributes (what the document lists as "extended" attributes). http://playground.sun.com/pub/nfsv4/draft/draft-ietf-nfsv4-00.html says: "Extended attributes are accessed by the new OPENATTR operation, which accesses a hidden directory of attributes associated with a filesystem object. " ACLs are listed in the "Recommended" bucket, albeit their structure is "to be determined". -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:09 AM Z CST