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