Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Soft links vs hard links (was Re: yet another 1.4 request)
Message-ID: <8907012203.AA21545@postgres.Berkeley.EDU>
Date: 1 Jul 89 22:03:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 91

:Doug Merritt		{pyramid,apple}!xdos!doug Writes:
:> Matt Dillon	Writes:

: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,

	Yah.  I apologize.

:>	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

	Yah.

: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?

	The cache hit rate system wide is usually >80%  The cache is part
    of namei().

	Frankly, I think we are all pretty much agreed that the efficiency
    is not really a problem so lets drop the point.

:>  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.

	One thing I would like to mention at this point.  In the many
    years I've used links I've used them almost solely to soft link
    directories to each other.  I soft link files about as much as I
    hard link files, which is never.

	Everybody I know who uses links generally uses soft links on
    directories only.

	Now think of the general case... with hard links (assuming you
    could hard link directories which you actually can under the proposed
    1.4 hard links) you are restricted to within a filesystem/device while
    with soft links you are not.  This may not seem to matter much for you
    single floppy people, but those of us with HDs would get seriously
    pissed if we didn't have soft links.

:>	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.

	P.S.  Anybody want to take a shot at what S.M.A.R.T. and
    S.T.U.P.I.D. stand for :-)  Best answer wins, er, well nothing.

: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!

	Just goes to show, never let Sun setup your system admin!

: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

					-Matt
>-- 
>