On Mon, 27 Jun 2005 22:59:24 -0400, Kyle Moffett <mrmacman_g4@xxxxxxx> said:/attr/fd/$FD_NUM == '...' directory for a filedescriptor
/attr/fs/$DEV_NUM/$INODE_NUM == '...' directory for an inode
[...]
These are not really "attributes" so much as they are "metadata", for
example, a "contents" subdirectory, if one existed, would be based on
the original file, and therefore non-unique, but would be looked up
based on information about the original file.
I think for most people on the reiser-fs list, the '...' directory
represents an interface to many things including
- automatic aggregating/tar/untar/compress
- a different interface to stat data
- adding extended attributes/substreams/acls/etc.
- anything else you might imagine
(I think this is your understanding too? Just double-checking.)
So some of that stuff would be separate from the file. (Separate in the
sense that it's not generated from the file's binary data.)
Personally, I don't like it all being in one directory, but it's not
that important.
Also, unlike a symlink, if the path doesn't change and the file does,
it will break, also, if the file is removed and another created
elsewhere, it will be redirected improperly. Perhaps a new symlink
syntax is needed to allow attribute specification (Ick, more changes
:-\).
I think those breakages are acceptable. (IMHO) In other words, I think
it would not occur very often without the user being aware of it, and
should very rarely result in catastrophic effects.
One other minor annoyance is it isn't easy to go backwards from the
... directory to the file. e.g. if I have a symlink that points to
/attr/fs/2/92036, I don't know what file's attributes that refers to.
Hopefully I'm sane enough to give the symlink a descriptive enough
name...
"meta" seems the more descriptive name. There should also probably be
a somewhat standardized location for this, such that programs can
locate it without much trouble.
Agreed. Ultimately, it's the user's decision where to put it, but
probably 99.99999% of all people will put it in the same place. Just
like you could put procfs or sysfs somewhere other than /proc or / sys if
you really wanted to, but nobody does that.
One other issue is that the attrfs/metafs needs to communicate with the
other filesystem somehow. It needs to know if the filesystem can handle
storing of extended attributes/substreams/etc. so that it knows whether
or not to allow those interfaces.
In my
/attr/fs/$(getattrpath /attr/fs/$(getattrpath ~/foo)/thumbnail)/ mimetype
example, it needs to be smart enough to store that in ~/foo's
filesystem. etc.