From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] book chapters
Date: Mon, 30 Jun 2003 19:40:56 +0100 [thread overview]
Message-ID: <e8b0dc29cb22e0958fac9086eabc9b49@vitanuova.com> (raw)
In-Reply-To: <3F006BC5.4070309@nas.com>
> 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.
next prev parent reply other threads:[~2003-06-30 18:40 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-27 9:47 pac
2003-06-27 10:22 ` matt
2003-06-27 22:08 ` Joel Salomon
2003-06-27 22:12 ` Geoff Collyer, geoff
2003-06-27 23:39 ` boyd, rounin
2003-06-28 1:03 ` Scott Schwartz
2003-06-28 2:10 ` Dan Cross
2003-06-28 2:27 ` Dan Cross
2003-06-29 17:55 ` Jack Johnson
2003-06-30 11:17 ` matt
2003-06-30 13:43 ` ron minnich
2003-06-30 14:02 ` matt
2003-06-30 16:56 ` Jack Johnson
2003-06-30 17:16 ` boyd, rounin
2003-06-30 17:19 ` ron minnich
2003-06-30 17:24 ` ron minnich
2003-06-30 17:29 ` boyd, rounin
2003-06-30 18:40 ` rog [this message]
2003-06-30 23:16 ` Kenji Arisawa
2003-06-30 23:24 ` boyd, rounin
2003-07-01 1:44 ` David Presotto
2003-07-01 11:27 ` Kenji Arisawa
2003-07-01 11:32 ` David Presotto
2003-07-01 9:51 ` matt
2003-06-27 22:36 ` William Ahern
2003-06-27 22:28 Joel Salomon
2003-06-27 22:26 ` Geoff Collyer, geoff
2003-06-27 23:43 ` boyd, rounin
2003-06-27 23:46 ` Geoff Collyer, geoff
2003-06-28 0:53 ` Dennis Ritchie
2003-06-28 17:44 A. Baker
2003-06-29 4:38 ` Dennis Ritchie
2003-06-30 18:17 Richard C Bilson
2003-07-01 17:48 A. Baker
2003-07-02 0:27 ` Dennis Ritchie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8b0dc29cb22e0958fac9086eabc9b49@vitanuova.com \
--to=rog@vitanuova.com \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).