From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] book chapters From: rog@vitanuova.com In-Reply-To: <3F006BC5.4070309@nas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 30 Jun 2003 19:40:56 +0100 Topicbox-Message-UUID: e1f0ea8c-eacb-11e9-9e20-41e7f4b1d025 > Where I have problems with matt's solution breaking down is when you > have worker_5 creating random sets of files in a traditional hierarchy. > Any subfolders he/she/it creates lose the rw permissions for the > bosses group, and even with the sticky bit set for the group you lose > those permissions the next level deep. actually, you're thinking in unix terms there. plan 9 has different semantics, such that the attributes of a directory *are* inherited. % cd /tmp % mkdir x % ls -ld x d-rwxr-xr-x M 9 rog rog 0 Jun 30 18:57 x % chgrp sys x % chmod 770 x % ls -ld x d-rwxrwx--- M 9 rog sys 0 Jun 30 18:57 x % mkdir x/foo % ls -ld x/foo d-rwxrwx--- M 9 rog sys 0 Jun 30 18:57 x/foo % > x/foo/bar % ls -l x/foo --rw-rw---- M 9 rog sys 0 Jun 30 18:57 x/foo/bar % > why not just a write a file server that mounts itself on / and implements > whatever policy you'd like to dream up? it would just implement the > policy, whatever that might be, and use the underlying filesystem to > store the bits. > > isn't it just protocol conversion? the problem is that if parts of that filesystem are bound elsewhere in the namespace, it's difficult to find out how to access the attributes of a particular file without knowing where it comes from. i've sometimes thought about a system where one might be able to access filesystem-specific meta-information on a file through that file itself. > I was wondering if you could even implement the data and resources forks > with 9p. The file would be somefile, with the actual data as > somefile/data > and resource fork under somefile/resource the problem with this is that *all* files have to be stored this way, or... you have to try and open "file", then "file/data", and reading the parent directory (the container of "file") doesn't tell you anything useful about the attributes of the files it contains (you have to ls */data). NeXTstep (and presumably now macos X) does something like this for applications, but it never seemed like a particularly elegant solution, as it's not transparent to code that really doesn't care about this kind of thing. to wander away from reality a little: one could add a 9p message, say "walkmeta", similar to walk, but which provides a fid that corresponds to the meta-information for a particular file. there is precedent for using a fid for out of band information: the fid created by attach and used by auth is just there to negotiate protocol meta-information. of course, what the conventions might be on such a fid is open to argument: does it just look like a file which can be read and written, or could it be a directory hierarchy (allowing meta-meta information, perhaps? :-]). to follow this flight of fancy a little further, suppose that walkmeta does provide a fid which can be further walked, and we add a new path separator, say "#", such that evaluating x#y means "walk to x in the normal namespace; then walkmeta to y". then one could imagine a scenario similar to the following: % ls -l x --rw-rw---- M 9 rog sys 0 Jun 30 18:57 x % cat 'x#acl' rog foo bar % echo add baz > 'x#acl' echo: write error: unkown user % cd 'x#.' % ls acl % pwd x#. % ls -l acl fs resource % ls -l 'acl#.' ls: acl#.: no metadata % just musing.