Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bbn!bbn.com!cosell
From: cosell@bbn.com (Bernie Cosell)
Newsgroups: comp.sys.amiga.tech
Subject: Re: filesystem links (was: yet another 1.4 request)
Message-ID: <42236@bbn.COM>
Date: 1 Jul 89 03:23:29 GMT
References: <8906300334.AA12228@postgres.Berkeley.EDU>
Sender: news@bbn.COM
Reply-To: cosell@BBN.COM (Bernie Cosell)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 90

In article <8906300334.AA12228@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
}:
}:$ 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, 
}:
}
}    From using soft links and hard links in UNIX systems it is clear that
}    soft links are much more useful.

Foo.  "much more useful" is clearly in the eye of the beholder: soft links and
hard links are DIFFERENT, they have virtually nothing to do with one another,
and neither can do the job of the other.  One links a name to a file-object in
a way that is *fully* symmetric with all other names linked to that
file-object, and the other maps a name in the file system into another name.
That is, one is name->file, the other is name->name.  VERY DIFFERENT stuff.

I agree with the original statement: there is a CLEAR need for both.  That we
might not be able to have both in a particular filesystem due to some design
decisions that were made long ago is unfortunate.  I happen to think that the
Amiga will end up with the less-useful kind.  Although I admit *many* otherwise
pretty sharp folk seem to be almost-completely baffled by how hard links work
(that they are not, really, 'links' in the same sense that a softlink is a
link).  What's interesting (to me at least) is that the confusion usually
results in folks thinking:
  (a) that the two kinds of links are sort-of the same thing, and so use them
      indiscrimately without understanding what they are doing (generally, they
      either learn to type "ln" or "ln -s" and never really have a clue what
      they're doing in either case).
  (b) they ascribe to this "link" operation some odd set of qualities which
      turns out to be something of a blend of the properties of the two, and so
      whenever anything even slightly out-of-norm happens they're guaranteed to
      be surprised (e.g., they can NEVER remember (and surely cannot figure
      out!) what happens when they "rm <hardlink>" versus "rm <softlink>"

}:As for hard links -- in Unix terms, the filename is in the inode under
}:AmigaDOS. That means you'd have to put the filename somewhere else if
}:you wanted hard links. 
}
}	The problem with hard links on the Amiga is that the filename is
}    part of the file header (the 'inode').  On UNIX systems the filename 
}    is part of the directory entry and not associated with the inode.
}
}    Thus, however hard links are implemented on the Amiga it will be a 
}    big hack.  I strongly suggest to C-A that they forget hard links 
}    entirely and implement softlinks (which they can do in a day).

To argue that it is *easier* to do without hard links in AmigaDOS is
fine (and I agree, as if that's worth anything :-)).  Unfortunately, I
suspect that if you can only have one, hardlinks are the more useful
one.  In fact, for all practical purposes you can *simulate* the semantics of
softlinks in application software if you have hardlinks (I like softlinks
plenty and use them a lot, but we got along just fine without them for a long
time, and it was no big deal: as I say, when we needed softlink semantics it
was easy to implement.  If you're only going to have one kind of link, at least
shoot for the one which is powerful enough to give you the effect of BOTH
kinds.

[and expanding on my comment above, when unix ONLY had hard links,
generally users fairly quickly figured it out, even the really-slow
ones... now that unix has both, almost EVERYONE that hasn't done any
kernel hacking gets confused... and it is usually because *softlinks*
have semantics that they don't expect (generally when the file
softlinked-to changes or goes away or moves and they find out about it
when something breaks in an odd way --  one of the one that KILL 'em is
when their softlink in turn points at a softlink (unbeknownst to them)
and it is a hop hidden insde someone *else's* hierarchy that went
away)).

And, the constant darkside of softlinks turns up over and over again:
there is the constant confusion about 'rm'... Very few folks have a
strong enough intuition about the differences between the two types of
links to be confident about what rm does on each (and find and tar,
etc).  And again, the confusion is almost always at the doorstep of
softlinks into play: with "hardlinks" there is complete symmetry.
There is no "original file" versus the "link", and so the operations
are easy to understand.  The asymmetry in softlinks (between the file
and the softlink to it) means that there will ALWAYS be confusion about
what will happen for any given operation: SOME have to act on the link,
itself, SOME have to act on the file, itself, and it is REAL hard to
get confident about which do which...

But, given that AmigaDOS _does_ have the file names (in essence) _in_
the files, you're probably right: taking a half-day to hack in
softlinks relatively cleanly is lots better effort expended than in
fighting to kludge hardlinks into a scheme to which it is clearly not
amenable.  Unfortunately, I think we differ in that I think that this
expediency will leave us Amiga-folk with the lesser of the two bits of
machinery.

  /Bernie\