[plug] Alternative Data Streams (From OT)

[James Devenish]

In message <Pine.LNX.4.33L2.0311081841060.4098-100000 at donau.golden.wattle.id.au>
on Sat, Nov 08, 2003 at 06:46:22PM +0800, Mike Holland wrote:
> Rather, ":" is a valid charater in a filename.

Actually, my point was that I was thinking of that as an advantage.
There's not really any room for alternative streams in UNIX (how about I
call them "forks"?), so trying to pretend they can be used with existing
Linux software is going to be silly (how should a file selector work,
for example? will `cp -r` work? etc.). But when would you want
alternative streams, anyway? Useful for bundling files together, I
suppose, and for storing metadata in particular. I can imagine that a
.deb would be easier to access if the data were stored in forks. But
this is basically storing metadata and it's probably better to use a new
API in any case. Also, Internet protocols are pretty unsuited to the use
of named forks. Another reason for wanting forks is to support Mac and
Windows files. Darwin's approach is already to use the '/' convention to
access a file's second fork, but it's too paradoxical for general use.
(The situation in Darwin is even more complicated, because '/' is a
valid filename character is Mac OS X but ':' is not, etc, etc.)

I was thinking that ':' would be useful because it stands out like a
sore thumb in Mac or Windows filenames but could also be used portably
amongst UNIX filesystems. A fork-aware filesystem would not necessarily
prevent you from using ':' normally. Though it *would* in some sense
limit your ability to mix forked files and ':'-containing filenames in a
single directory. I have been thinking that one way of approaching the
problem is to store forks in regular inodes. Internally, the filesystem
would flag forked files differently from regular files, though it should
present forked files as regular files in 'stat', etc.  By using normal
inodes for the forks, you retain all the normal metadata (e.g. mod time,
access time, block usage, ownership, etc.).

The disadvantage of using '/' as the separator is that you couldn't move
forked files from one filesystem to the next -- you would have to split
them up into separate files. This would mean using 'magic' directories,
etc. Moreover, you would then have to modify all pathnames that had
referred to those forks. If ':' were instead used as the forks
separator, neither of those problems would arise. You wouldn't
necessarily be prevented from using filenames that contain ':',
either. For example:

% echo default > file
% echo default > anotherfile
% mkfork file # this is hypothetical
% echo alternative > file:rsrc
% echo alternative > anotherfile:rsrc
% ls
anotherfile anotherfile:rsrc file
% cat file:rsrc
alternative
% forktool -x file # this is hypothetical
% ls
anotherfile anotherfile:rsrc file file:rsrc
% forktool -c anotherfile file # this is hypothetical
% ls
anotherfile file
% cat anotherfile:rsrc
alternative

forktool would not have to make or remove inodes, because the forks were
already stored with inodes. Moreover, the duality provided by "forktool
-x" and "forktool -c" would allow you to move files between fork-support
and fork-ignorant filesystems without encountering the "cannot write to
a directory" UNIX problem. An obvious constraint would be that fork
names could not contain ':' or '/'. So:

% forktool -c Some::Perl::Module
forktool: invalid operation

> Get some sleep :-)

Please don't use dirty words like that ;-)


_______________________________________________
plug mailing list
plug at plug.linux.org.au
http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug