On Sun, Jan 06, 2002 at 12:39:05AM +0100, Jens Benecke wrote: > I don't know if there are any (printable) characters that are NOT allowed > in Unix file names yet but if there are, use those.
They are '/' and '\0' Anyhoo the following needs to be pointed out. 1) I question the need for metadata capabilities to end up in ReiserFS (or ext2, or ext3) at this time. 2) I see a lack of consensus about what sort of metadata should be grafted onto files, yet I already see questionable arbitrary limits appearing. Perhaps some of the advocates could make references to userspace rich file format APIs that provide the functionality you seek. [1] 3) Given some APIs, perhaps a common API wrapper that the average coder could be encouraged to use correctly and manages to work on common desktop and server operating systems. 4) Given an API, create a usermode filesystem that makes the extensions transparent[2] to programs that don't use the API and work out the interface issues. 5) Once the usermode filesystem has reached a point where it doesn't give Al Viro nightmares, start moving the new functionality to the common VFS layer. 6) Once the extensions are in the VFS layer, consider tweaking existing filesystems to handle the extensions more efficiently. 7) All of this appears to be an attempt to graft the behavior of a single level store operating system (Like OS/400 or Mungi) onto the Unix model. I wonder if it would not be more efficient to adapt a single level store system to desktop use, now that they ship with POSIX subsystems. [1] I would like to thank the person that mentioned XML although that's a bit later than the API :-). [2] Then again, I would rather see rich file that can be manipulated by command line file and directory manipulation tools flagged as a filetype other than "file" or "directory", so much for transparent. -- Chris Dukes "Bert is apparently EEEEVIL, whereas Oscar is just a sysadmin^Wgrouch." -- gorski