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

Reply via email to