Re: Carrying Attributes too Far

["Alexander G. M. Smith" <agmsmith@rogers.com>]

Bennett Todd wrote on Fri, 19 Sep 2003 09:46:31 -0400:
> If someone were to want to attach an icon to a directory describing
> what it contained, that'd be an opposite case; stat should still
> report the internal node as a directory, you shouldn't see the icon
> unless you explicitly tried to open that internal node with a file
> open syscall.

The icon would be in a file (or rather, use the file-like behaviour of a fildirute thing).  The icon would be a child of the main directory, and have a standard name that the GUI recognises (like "thumbnail" or "icon").  In our latest discussions, after a suggestion by Narcoleptic Electron, we've agreed that putting attributes in a special subdirectory to segregate them from the ordinary directory contents is a good idea.  In that case, the icon would be inside the ",," directory which is inside the main directory.

In the fildirute view (things are both files and directories, stat() returns something new):

MainDir                  (the main directory we're talking about)
MainDir/,,               (a directory storing MainDir's attributes and
                         metadata.  Note that it isn't a full directory, it's
                         just generated by the system to keep metadata
                         separate from the contents.  ",," can't have its
                         own attributes - it may be implemented as a bit flag
                         on each thing rather than as a real directory)
MainDir/,,/MIME          (type of the MainDir, contains "application/directory")
MainDir/,,/icon          (a fildirute Thing that contains the icon data)
MainDir/,,/icon/,,/MIME  (MIME type of the icon)
MainDir/SomeFile         (a regular child of MainDir)

Or if we use a Janus (two faced overused god) mapping to POSIX files and directories, where the ,, child is recreated as a directory with a similar name to its parent:

MainDir                  (a directory)
MainDir,,                (a directory)
MainDir,,/icon           (the icon file contents)
MainDir,,/icon,,         (a directory)
MainDir,,/icon,,/MIME    (a file containing the MIME type of the icon)
MainDir/SomeFile         (a file)
MainDir/SomeFile,,       (a directory with metadata for SomeFile)


Back to the original argument, instead of using a directory to separate attributes from contents, can't we mangle the names?  If we could put up with the name space corruption, we could just prefix all our metadata Things with ",," or ".." and mix them in with the regular fildirute Thing "directory" contents.  Standard tools would be able to operate on both metadata and regular data, which is good from the namespace side.  Plus we wouldn't have to worry about creating a magic ",," directory, which isn't like other directories (no attributes attached to it, etc).  So long as users don't name things starting with a pair of commas (or periods), it should be OK, though not philosophically elegant.  Hmmm, didn't I see "..userid" somewhere?  Looks like I've come full circle to what already existed!

In Hans Reiser's Reiser4 paper: "An interesting question is whether or not all of these hidden files should have the same name prefix (e.g. '..' at the start of the hidden name). I am still soliciting input on this. Note that this feature should be used for special files that one does not want to be backed up."

Oh, ok, guess we should use ",," as a prefix (or directory name) for metadata like attributes, since they should be backed up.

- Alex