[plug] Alternative Data Streams (From OT)

[James Devenish]

In message <20031109053505.GE726 at erdos.home>
on Sun, Nov 09, 2003 at 01:35:05PM +0800, Cameron Patrick wrote:
> But surely you wouldn't be able to move files with forks between
> fork-supporting filesytems and non-fork-supporting filesystems anyway?
> And presumably tools like cp, etc would have to be modified to deal with
> forked files no matter how they are implemented[1]?  Or maybe I'm just
> misunderstanding you.
> 
> Cameron.
> 
> [1] fileutils, for instance, currently links to libattr and libacl so
> that it can handle files with (XFS-style) extended attributes and ACLs.

I presume that one of the reasons that people would want to be able to
access metadata and forks using '/' is that they want to access those
things using pre-existing software and pre-existing habits. You would
expect, for instance, to be able to 'cat' forks (I'm not going to call
them streams because we already have streams, STREAMS, and probably
StReAmS). You could also expect to be able to 'cp' metadata and forms,
as you mentioned. Of course the proper way to do with is to rewrite your
software, but...there's a lot of software out there. On the 'plus' side,
there has been a lot of success rewriting software for 64-bit (or
greater) support, UTF, IPv6, etc. So...it will probably happen on day.
Nevertheless, it will probably be decades before most people could
seriously consider avoiding interactions with software and systems that
don't support forks.

If there were a way of intermixing ignorant and aware software while
retaining the advantages of aware software, that would be nice. The idea
that I posted was that you could swap bewteen ignorant and aware at
will. For example, what should dirent.h do for ignorant software and
what should it do for aware software? You might suspect that for
ignorate software, readdir should return forks as separate entities so
that ignorant 'cp' would work as though it were aware. An 'aware' verson
of 'cp' would instead see a forked file as a single entity with 'I am a
forked file' metadata. The result of using igorant 'cp' would be that
you have lots of unforked files. This would be temporarily inconvenient
because you could thereafter not 'cp' or 'mv' all forks atomically.
Fortunately, this would be obvious in 'aware' programmes because they
would start listing forks separately. 'forktool' could be used to fix
that up. Basically, you could swap between forked and unforked without
having to modify your software or its configuration. Probably not a
technical reality, but that was the idea I had.

In the case of forks, you also have a problem in maintaining the very
useful distinction between "files" and "directories". Often, this is
largely an illusion, yet it is useful for we humans. I think we would
want forked files to be fairly obvious and easily examined in full
(unlike what I have heard about NTFS on this list). So...more rewriting
of software?


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