> > You still are stuck with breaking normal utilities, though, unless
> > you provide some integral way of wrapping the "bundle" up into a
> > flat file, if you try to read directly from the forked "directory".
>
> Such cp, etc. aren't aware of data forks as is though, and making
> them fork aware is as hard as making them work recursively if not
> harder.
>
> cp -r will however work, and high-level stuff like KDE/GNOME whatever
> will be able to tell what is really a file and what is really a
> program-package or whatever and treat it appropriately for those in
> the pointy clicky world.
Hmm, interesting point.
> I really fail to see one single advantage of multiple forks over
> directories. Not one.
Well, one good thing about forks is that they are lightweight, and the
"data fork" (fork 0, really) can always be treated as "the whole file" by
unintelligent programs.
That's the real benefit of the resource fork, actually -- to be able to
stuff new data, and arbitrary data, into a file, with a semblence of
organization, and then be able to do useful stuff with it, without
confusing existing programs.
This definitely is not possible in the directory fashion. Consider the
normal (for the Mac, at any rate) approach to storing editing info
(current line & col, for example) as a bit of information in the resource
fork of a source code file. This works just about perfectly, and trivial
programs simply ignore the resource information when they read from the
data fork (which contains the desired source code, in the usual ASCII
format). But in a directory system, there is no way to transparently
change "foo.c" into "foo.c/data", at least not without some tricks in the
VFS, or much smarter applications. (The closest we've ever come is the
emacs & vi local-data sections, which is hardly transparent.)
None of this is a technical difference between forks & directories -- I
doubt there is one, really. It's just a matter of what the OS and
libraries are set up to do, and Unix does _not_ have the concept of
resources.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html