Agree with most of the stuff you wrote. On Tue, 28 Jun 2005 00:38:38 -0400, Kyle Moffett <[EMAIL PROTECTED]> said:
> On Jun 27, 2005, at 23:45:00, Hubert Chan wrote: >> 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 > Ok. Those things should probably be divided up. Stuff like POSIX > extended attributes and such that have existing interfaces should use > those. One of the claimed advantages of the '...' interface is that everything is editable as a file. So if someone wanted to edit the description extended attribute for foo.txt, he would just run "[editor] foo.txt/.../description" (or "[editor] /meta/fs/$(getattrpath foo.txt)/description"), instead of needing to use some special purpose editor. It works well for things like being able to use Gimp to edit a thumbnail or icon attribute. Of course, it shouldn't be too hard to provide both interfaces, as long as you get locking and caching right... The Reiser4 file-as-dir interface is also supposed to be more flexible than POSIX extended attributes. For example adding attributes to attributes (e.g. adding a mimetype attribute to a thumbnail attribute). The point of it is to present many different things (extended attributes, file manipulation magic like automatic compress, etc.) through a single interface that everyone knows how to use (i.e. regular files) so that people can use regular programs to edit or manipulate them. The inspiration, I think, was the MacOS X/NeXTSTEP bundle format. For example, MacOS X/NeXTSTEP .app file is actually a directory that behaves much like an executable file (double-clicking a .app file in the Finder launches the application, instead of opening the directory). However, it is in reality a directory that contains many things that could be thought of as extended attributes (such as the application icon, information about the application, etc.). Since the application icon is a real file, it can be edited by normal graphics editors (not like Windows programs, where you need a special icon editor). And since it's inside the .app directory, it's attached to the application (not like Linux, where the program is in /usr/bin, and the icon is in /usr/share/pixmaps), so it makes package management easier (to delete an application, just delete the .app file -- don't need to look in /usr/share/pixmaps for the icon and delete it). > Other types of data should chose other interfaces that make the most > sense for that type of data. I think that the /meta fs should > probably only be used when the data is generated from the existing > file or directory, and perhaps a few other cases. [...] >> 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... > I don't see this occurring often enough to be a major problem, I don't see that this should be a major problem either, but I thought it was worth bringing up. > and in any case inodes are not path-exclusive (think hardlinks). If > they have the filedescriptor open, however, they could use > /proc/$PID/* to figure out where the file is. Although I guess if they have a file descriptor open, they probably have the original filename lying around somewhere... [...] > On another note, it's nice to see the flamewar has died out and > several technical discussions are taking place on various levels :-D. Agreed! :-D -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.