Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!motcsd!xdos!doug
From: doug@xdos.UUCP (Doug Merritt)
Newsgroups: comp.sys.amiga.tech
Subject: Re: filesystem links (was: yet another 1.4 request)
Summary: How about a feature *superset* instead of *subset*
Message-ID: <392@xdos.UUCP>
Date: 27 Jun 89 16:13:20 GMT
References: <0933.AA0933@caleb> <1989Jun16.151408.8382@ziebmef.uucp> <3940@sugar.hackercorp.com> <19856@cup.portal.com> <112459@sun.Eng.Sun.COM>
Reply-To: doug@xdos.UUCP (Doug Merritt)
Organization: Hunter Systems, Mountain View CA (Silicon Valley)
Lines: 82

In article <112459@sun.Eng.Sun.COM> page@sun.UUCP (Bob Page) writes:
>[This really belongs someplace else.  Followups to comp.sys.amiga.]

Disagree. Technical issues are involved, the only reason to avoid .tech
would be the assumption that all .tech'ies are Unix-heads who know all
about links, which ain't true. I've been wanting to talk about how
links *should* be implemented on the Amiga, and why, ever since I
found out that "the obvious way of doing it" isn't the way that certain
people are planning an experimental implementation.

>Another use is to name one program differently based on what you want
>to use it for.  For instance, Matt Dillon's 'backup' and 'restore'
>programs are the exact same code.  Same with 'compress' and
>'uncompress'.  They know how to act based on what they are called.  If
>you don't have links, you have to duplicate the code on the disk, so
>you might have two 100K files, one for compress and one for uncompress.
>If you have links you link them together and you're only taking 100K
>(plus the link overhead but that's not worth including).

This is a very important usage. Other examples: 'vi' is linked to 'ex'
is linked to 'edit' is linked to 'view'. Also 'zcat' is linked to
'compress' and 'uncompress' (and I keep wanting to do this particular example
on my Amiga).

Another usage, somewhat similar to some you cited, is to put the file
name (link) wherever convenient, but to put the massive body of the file
onto whichever disk has sufficient space. Thus I experimentally compile
somebody's 50 megabyte source in my own local directory, using a link to
point at the source to avoid copying it, and can avoid overwriting the
results of *their* compilation. Naturally most people don't have to deal
with such large source, but the principle applies in general.

Similarly I set up Usenet news on a free 100 Meg disk partition, and
by providing appropriate links, it appears as though it is set up on
everybody's own local file system. (This can also be accomplished by
rmounting, but much less flexibly.)

Note that the latter applications require cross-device links.

>Hard links and soft (or symbolic) links are just different
>implementations of the same idea under UNIX, each with its own
>strengths and limitations.  Under the Amiga FS in the non-existant
>v1.4, all links are soft links.  However, UNIX-heads have come to
>think of soft links as being able to cross file systems, and the FS
>links under the non-existant v1.4 don't.  So there's some effort to
>provide a cross-filesystem link "above" FFS, somewhere at the DOS
>level.  This may or may not happen.  And of course I'm making this up
>because v1.4 doesn't exist.

This is the same old story we've been dealing with for the last decade.
Unix has its problems, but it also has some really superlative strengths
(Berkeley Unix, anyway). And every time some other OS adopts a *subset*
of the features, the incompleteness always turns out to be an annoyance
to those who've gotten used to the conveniences of Unix features. Ten years
ago I was writing Unix utilities (more, diff, grep, etc) for CPM to bridge
the convenience gap. Now it's a question of what kinds of links, etc.

To me it's obvious that "subset" isn't good enough. When can I have
a system that has a *superset* of the features of Unix???

There's a clear need for both hard and soft links, and someone who hasn't
used both kinds in the past probably won't clearly understand why, but that
doesn't make it less true. In fact there's a clear need for other kinds
of links, too, e.g. to support hypermedia-ish tools. Active links that
trigger servers, for instance, which I designed into a circa '82 mainframe
OS, but which still aren't generally available in any mainstream OS. At
least Unix V.4 will have a process FS, again an old concept but not one
being considered for AmigaDos yet.

The Mac pioneered resource forks years ago, and while they have their
problems, they provide some minimal functionality that any OS designer
should be taking very very seriously today. The lack of resources in
AmigaDos is a real shame (right, Chuck? :-).

Two steps forward, and one back. The reason that the state of the art of
software is so primitive even now is that people are always aiming towards
a minimally justifiable set of features instead of looking forward to
a maximally generalized set of features. Sigh.
	Doug
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary