FAQ/streams

We would like to implement for ReiserFS the functional equivalent of streams by expanding current directory functionality. I'll wait until we are ready to perform active coding on this before sending a long email with a proposed architectural definition, but I'll highlight the main features here since this seems to be an active thread at the moment.

• Inheritance of stat data.

• Inheritance of filebodies with inheritance being specified by writing to some name like filename/.meta.

• Objects that are both files and directories (the sticky point here is telling open whether to open it as a file or a directory. Linus seemed to have resolved this though in this thread on lkm.) The filebody is that file within the directory which is set as the default filebody for the directory by virtue of it having a link to the name .anonymous (or some such name).

• Hidden entries (ala .snapshot directories on Network Appliance servers) which open()/lookup but not the default readdir() method sees.

• Attributes (including stat() data) are to be such hidden entries and accessible as normal files if you choose to explicitly name them.

• read() on the file directory_name_fu/.archive (or some such name) returns an archive (written in something not far from the format of the inheritance syntax) containing the directory tree rooted at directory_name_fu (and there should exist a write() plugin method for reiserfs such that cat'ing an archive file of the right syntax to directory_name_fu2/.archive causes the archive to get unpacked as directory_name_fu2.) I agree that tar is an ugly format.

I'd like to encourage folks to consider Viro's valid concerns as the breaking of the egg that precedes the omelette. We should minimize breakage to the extent that we can without losing our desired functionality, but if we cease to innovate for fear of growing pains then the OS dies.

I think that we can do stream functionality much better than NT or Mac by carefully analyzing what streams give people that is useful, and then implementing each such thing as a separate orthogonal feature. NTFS streams have properties that are rigidly bound to each other, and if we orthogonalize/decouple the features the expressive power goes way up. A. to F. constitutes my analysis so far.

Using the above features a file with all that we value streams for in it can be implemented as:

1. a directory containing a .anonymous file that contains the default stream. Depending on the GUI objectives, this .anonymous file might be a symlink to .archive
2. All of the files in the directory are set as inheriting their stat data from the parent directory.
3. GUI tools learn to use the .archive feature for moving things.

I think Migel is right that Windows does some things better than Unix, and we should think about what is better, and then do their good stuff better than they were able to. I think that the timing might be right for Linux to start trying to be more than Unix/NT/Mac has ever been before us. In the past it made sense to just try to catch up to them. Now 2.4 has gotten us caught up to them in the bulk of their features. He who has the dominant market share needs to lead the pack, or else the pack will lose to other packs as it mills around doing nothing. Linux dominates the Unix market nowadays.