🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #274

Soft links vs hard links (was Re: yet another 1.4 request)

#274
From: Matt Dillon
Date: Fri, 30 Jun 1989 20:04
160 lines
7761 bytes
:In article <8906300342.AA12274@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
:>
:>	Soft links are better than hard links period.
:>
:>	* Removing a softlink removes the softlink, NOT the file it is pointing
:>	  to
:
:And yet there are times when you want to set things up so that removing
:the softlink *does* remove the file itself, if the file (inode) reference
:count goes to zero. This can't happen with soft links, where only one
:of the file references is the real file.
:
:>	* You can create soft links to non existant (or not yet existant) paths
:
: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.  And as far as complaining if the file does not
exist, you get *that* when you try to open it.  

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

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

:>	* You can have soft links across filesystems
:
:On Unix, using hard links to files on the same file system
:gives a performance advantage over soft links, since opening the
:hardlink immediately gives the inode reference, whereas soft links

	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.

	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.

:require a second path search to find the real inode. So far it seems
:to me that the same could be true on AmigaDos.
:
:>	* You can have soft links to devices
:
:Bogus, on both AmigaDOS and on Unix you can hard link to devices. On
:Unix you just do it; "ln /dev/tty ~doug/my_tty" works. On AmigaDOS
:you can create a second device list entry, or do an assign. 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.

	An assign isn't a softlink.  A second device list entry isn't
a softlink.  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.

:
:>	* It doesn't require any hacking on low level FS structures
:
:Implementation detail.

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

:>	Hard links are dangerous because:
:>
:>	* They are not easily supportable under AmigaDOS due to the filename
:>	  being in the file header (inode) instead of the directory entry
:>	  (what directory entry!).
:
:Implementation problems are a secondary issue after consideration of
:desirability.

	But we consider it anyway.  Your opinion, sir.

:>	* backup programs would have to deal with circularities and, even when
:>	  found, since there is no distinction between a master or slave link
:>	  the user can get very very confused.  At least with soft links you
:>	  know where you stand.
:
:The circularites don't come about on Unix because you are prevented
:from hard linking to directories. Multiple backups are prevented on
:AmigaDOS by the archived protection bit. I grant you the confusion, except
:that even soft links can lead to a great deal of confusion, as we find
:out daily on Sun 3.5. (And on Sun 386i 4.0, they lead to nothing *but*
:confusion due to brain damaged system setup. But that's Sun's problem.)

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

	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.

	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.

:
:>	* Hardlinks look like normal files or directories... all the more
:>	  confusing.
:
:Harlinks *are* normal files (but again, not directories). The only
:point of confusion with hardlinks is that you may not know where
:other copies of a file are, but "find . -inum ..." can fix that in
:the rare cases where it matters. In any event, it's not clear that
:a small amount of confusion means that they should be tossed altogether.

	Most people are used to the idea of a file being in one place...
    A softlink retains this idea.  There is a known 'master' (the real
    file) and any number of 'slaves' (the soft links).

	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.  I
    have never come upon a situation where I would want to use a hard link
    instead of a soft link.  The two times in the past where I did use hard
    links led only to confusion (and anyway didn't survive being tar'd).

        And, as I said above, if you are root you *can* hard link directories.

>Especially considering that soft links really are *more* confusing. I
:hate to do "cd directory; cd .." and discover that I haven't returned
:to where I started. This never happens with hard links.
:	Doug
:

	Not confusing to me.  If it confuses you just don't go cd'ing into
soft linked directories.   Well, I'll be honest.  When I began fooling around
with soft links it *did* confuse me, but it only took a couple of days to
get out of the bad habit of being confused by it.

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

>Doug Merritt		{pyramid,apple}!xdos!doug
>Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary

				-Matt
Technical Details
Message-ID: <8906302004.AA16719@postgres.Berkeley.EDU>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Soft links vs hard links (was Re: yet another 1.4 request)
Message-ID: <8906302004.AA16719@postgres.Berkeley.EDU>
Date: 30 Jun 89 20:04:11 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 160