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: Soft links vs hard links (was Re: yet another 1.4 request)
Message-ID: <401@xdos.UUCP>
Date: 1 Jul 89 02:15:13 GMT
References: <8906302004.AA16719@postgres.Berkeley.EDU>
Reply-To: doug@xdos.UUCP (Doug Merritt)
Organization: Hunter Systems, Mountain View CA (Silicon Valley)
Lines: 175

In article <8906302004.AA16719@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
In a lost attribution, I said:
>:And yet there are times when you *want* a complaint if the file doesn't
>:exist yet, or to be able to preserve a file simply by linking to it.
>
>	Bull.  Never in my life have I wanted the removal of a softlink to
>remove the actual file.

Since I didn't say that about *softlinks* I'm not sure how to reply to that.
If you meant "hardlinks" then see below.

>And as far as complaining if the file does not
>exist, you get *that* when you try to open it.  

Sure. This is like the difference between early and late binding in
languages. If I'm setting up something for myself or others to use later,
I need to double check things *at the time the link is made* to make sure
I did it right. This is a perhaps coincidental side effect of hard links
that can be handy.

Naturally this effect could duplicated by a new flag to a link command,
like "ln -sc file1 file2" to check to make sure the original exists before
creating the soft link.

It may be that *everything* I'm saying is useful about hardlinks on Unix
can be gotten via variations on the theme of softlinks in a similar way,
I don't know yet. So far I'm just point out situations wherein hard link
semantics can actually be handy.

>	Are you truely arguing things that you have utilized or are you just
>thinking up cute things to say?

Aw, that's not fair. I thought it was a pretty clear example. The last
time it happened, someone said "there's a compiler bug triggered by tmp.c,
check it out but don't screw with it because I'm still using it." Being
thrifty, I make a link to it rather than copying it. If hard links are
available, I use them, and both of us can delete our links whenever we
are done with our independent uses of the file. With soft links, the
owner of the original file must double check with other users of
the file before deleting it. This sort of situation has come up just
about every time I've ever done long term work as part of a group on Unix.

>:With hard links, you can link to someone else's file, and they can delete
>:it when they're done with it without worry, because you can do the same
>:independently. With soft links you'd have to take the extra steps of
>:copying the file somewhere safe, replacing the original sole definition
>:of the file with a soft link, and then eventually coordinating with 
>
>	What !!!??  Bull.  What *are* you thinking about?  Soft links work
>a certain way and the idea is to use them that way, NOT to complain that
>they don't do *exactly* what you want in *some* cases when the workaround
>is incredibly simple the problem should never have been mentioned in the
>first place!

This is a very strange reply. I'm talking about situations in which
I have found hard links to be handy, and you say that I shouldn't complain
that soft links work differently than that??? But to say that, you have
to have already taken the position that hard links aren't worth implementing,
which presupposes the point in question!

As for the point about a workaround being simple, for years non-Unix people
have been saying the same about *any* kind of link...the workaround is
to copy the file, what's the big deal? But that misses the point: it
is usually better to have a feature than to have to find a workaround.

>	On Unix, hard links are easy to implement.  Also note that on
>Unix BSD 4.3 and beyond, and many 4.3 compatible systems now implement
>a cache of recently used paths.  The overhead for a cached soft link is
>virtually the same as for a hard link, so much so that nobody notices the 
>difference.  Also, such overhead occurs on stat()/open() only.

Ok, that's a good point. That argues that there is less performance
advantage to hard links that I implied. On the other hand, since caching is
a context dependent and probabilistic win rather than a 100% improvement,
it does not fully negate my point about performance. What *is* the
expense of namei() in such Unix systems?

>	Not to say there is no overhead.  There are many places where I
>have soft links across an NFS and that can get very slow when one is stat()ing
>a mess of them.  But then again you can't hard link across devices anyway so
>the point is moot.

Agreed.

>:>	* You can have soft links to devices
>:
>: And if AmigaDOS had a consistent name space, where device names *really*
>:lived inside a file system, then you could just plain link them, too.
>
>  And hard links to devices are restricted to being on the SAME
>FILESYSTEM.  Most UNIX machines do not have /dev mounted on the same partition
>as their users.  Why yours does I can't guess.

Well, it happens. But the point was that you *can* hard link to them.
There's nothing different about a device; if the device is on a different
file system then you have the exact same considerations that you have
for regular files.

>	The fact remains that hard links are more difficult to implement
>	while soft links are trivial to implement, and more powerful to boot.

Agreed.

>	Well, you *can* hard link directories on UNIX but you have to be
>    root to do it.

So? In real life, root doesn't do that. Root has the *ability* in order
for the semantics of mv, mkdir, etc to work correctly. It is not
otherwise exercised.

>	Multiple (circular) backups on the Amiga are NOT prevented by the 
>    archive bit.  Only stupid (S.T.U.P.I.D) backup programs fix the bit
>    (and thus write to the HD) as they are backing up ... the proper way
>    to do it is to take a second pass on the HD *after* you have finished
>    backing up to fix the bit.

Good point, I missed that. The smart (S.M.A.R.T. :-) backup programs on
unix fix the redundancy problem by keeping track of inodes.

>	I have seldom been confused by soft links.  They are not true hard 
>    links in that they aren't quite transparent (i.e. rm removes the soft
>    link) but they do the job they were meant to do.

Well if you can reverse yourself, then I can too: neither soft links
nor hard links are confusing to me, I was just saying that to be agreeable
(Since we're taking the high moral ground here the corollary is that naive
users are confused by everything, so to hell with 'em :-) :-) :-)

>	Most people are used to the idea of a file being in one place...

Yes.

>    A softlink retains this idea.  There is a known 'master' (the real
>    file) and any number of 'slaves' (the soft links).

Not exactly "known" in practice until you've memorized a configuration.
You have to ask for a long listing to see where the "known master" is,
and even then, it may be (often is) another soft link!

>	With a hard link this idea goes down the drain and people who
>    like to think of a physical file being in one place, get confused. 

Ask someone who administers a system that uses lots of soft links (e.g.
Sun 386i) whether anyone ever gets confused as to where things actually
are!

>:hardlink to Unix directories because those exceptions don't seem
>:important in this context.
>
>	That root can?  Well, I'm not going to delete my references to
>	the ability.  Since you were so hot on telling me you couldn't
>	hard link directories don't think you put yourself off the
>	hook by saying at the end 'oh, by the way, you *can* hard link
>	directories'.  sheeessh.

As you yourself know, root-as-user-id-in-system-calls can do almost anything
on Unix, mostly to make it easy to implement critical and trusted utilities
like rm, mkdir, rmdir, etc. This is very different than what root-as-a-
logged-in-user can do; the superuser *cannot* make links to directories
on most Unix systems because the standard utilities prevent him from
doing so. And on systems where the superuser *can*, he doesn't, precisely
because it screws things up and he's not supposed to do that.

You're unfortunately obscuring the issue by mixing in the details of
*how* Unix achieves its design philosophy with *what* the final effect
of the philosophy is.

Since you have the expertise to know what I'm saying already, I guess it
happened because you were so eager to make me eat my words, and leapt
at the superficial contradiction. Let's be both more friendly than that,
and also more thorough than that.
	Doug
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary