Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!csd4.milw.wisc.edu!leah!rpi!pawl!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Soft links vs hard links (was Re: yet another 1.4 request) Message-ID: Date: 1 Jul 89 00:11:39 GMT References: <8906302004.AA16719@postgres.Berkeley.EDU> Sender: usenet@rpi.edu Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 300 In-reply-to: dillon@POSTGRES.BERKELEY.EDU's message of 30 Jun 89 20:04:11 GMT Time to jump in here, I guess. In article <8906302004.AA16719@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >In some article, Doug Merrit writes: >>In article <8906300342.AA12274@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >>> Soft links are better than hard links period. Subjective statement, open for debate. >>> * Removing a softlink removes the softlink, NOT the file it is >>> pointing to Removing a hardlink removes the hardlink, NOT the file it is pointing to. Removing the *last* hardlink causes the file to actually be removed. >>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. Awkwardly stated, but such occasions do arise. >>> * You can create soft links to non existant (or not yet >>> existant) paths Which can be good or bad, depending on the situation. >>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. (Yes.) > 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. Nor will removal of a hardlink remove the actual file. On the other hand, removing of the sole hard link to a file with softlinks pointing to it WILL invalidate those softlinks. (again, desirability thereof depends on the situation._ > Are you truely arguing things that you have utilized or are >you just thinking up cute things to say? I don't know about him, but I've had occasion to use hardlinks. >>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 This is a dangerous ability... consider a system with user quotas. You can create a hardlink to a file of someone else's, (core files are ideal) and hide that hardlink in a depermitted directory. They can remove their hardlink to the file, but as there remains a link, the file remains, still owned by the original owner. Thus, the file still count's against the user's quota, yet the user has NO way to destroy the file. Because of this, the ability to make hardlinks should be restricted to the owner of the file or root. (a workaround -- cp /dev/null coreto overwrite the file (and empty it) and then remove the link.) > 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! Softlinks and hardlinks both have their place. There ARE situations where a hardlink is preferable, even though softlinks are more flexible in general. >>> * You can have soft links across filesystems A clear advantage. (more flexible here) >>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 require a >>second path search to find the real inode. So far it seems to me >>that the same could be true on AmigaDos. A clear advantage of hardlinks. > 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. Hard links are trivial to implement under Unix. Saying cacheing will make up the performance difference is a bit of a straw man... you could as easily say that Amiga directory listing is plenty fast, if the relevant sectors are cached... but it doesn't change the high overhead of the directory scan, cached (memory overhead) or not (speed overhead). > 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. Ever taken a look at the system setup of a Sun 386i? Serious brain damage, here... >>> * You can have soft links to devices AmigaDOS separates devices from files, unlike Unix. This may or may not apply to an AmigaDOS implementation of softlinks. >>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. (only if on the same filesystem -- unlikely. ("ln /dev/tty /tmp/tty" would probably work, on the other hand.)) > 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. No, an assign is halfway between a hardlink and a softlink. (think about it.) >>> * It doesn't require any hacking on low level FS structures >>Implementation detail. But a considerable one. > 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 more difficult to implement under AmigaDOS because of the backpointers, yes. This IS an acceptable reason to put it off, but soft links would be relatively easy, and SHOULD be implemented. Softlinks are generally more flexible than hardlinks, but hardlinks DO have their place. >>> 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!). Poor FS design, now very ingrained. Considerable implementation difficulty, but hardly to be considered a "danger". >>Implementation problems are a secondary issue after consideration of >>desirability. Depends on degree. > But we consider it anyway. Your opinion, sir. Not to be ignored, certainly. >>> * 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. Hard links to directories can cause serious problems, and are thus generally avoided (as well as being restricted to root.) >>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. At times. >>(And on Sun 386i 4.0, they lead to nothing *but* confusion due to >>brain damaged system setup. But that's Sun's problem.) Agreed. > Well, you *can* hard link directories on UNIX but you have to > be root to do it. But it is strongly discouraged because of the dangers involved. > 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. Separate issue. > 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. And rm removes a hardlink, too. Hardlinks remain useful. >>> * Hardlinks look like normal files or directories... all the >>> more confusing. They ARE normal files. A file hardlinked to another is simply two normal files, except that they share contents. Think of them as "composite objectS" in PostScript or even just strings (or structures) in C... You can have two equally valid pointers to the same memory area. Saying you should always make softlinks to files and never hardlinks is like saying "only pass around char **'s to a string, and have only one char * for each string..." (granted, a difficult analogy, (seems absurd) but it does apply, at least in part.) >>Hardlinks *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. Exactly. > 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). And hardlinks maintain the concept of "equals"... all links are "the real file" and none of them depend on the other links' existance. > 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 file remains in one place, you merely have different pointers to it. A hardlink is a pointer to the actual file, while a softlink is a pointer to another pointer. (either the real hardlink, or more softlinks.) > The two times in the past where I did use hard links led only to > confusion. Now, shouldn't an accomplished C programmer like yourself have a more thorough understanding of pointers? ;-) > (and anyway didn't survive being tar'd) On *this* Unix system (SunOS 4.0) tar happily identifies files hardlinked together, and will recreate them faithfully. > And, as I said above, if you are root you *can* hard link > directories. But who WANTS to? For directories, I can never see hard links as being better than softlinks. For files, it's different. >>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. This WOULD happen if you hardlinked a directory... The ".." entry in the directory would point only to its original parent directory. > 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. Many things are confusing at first. >>hardlink to Unix directories because those exceptions don't seem >>important in this context. Not particularly, no. > 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. You *can* but it is exceedingly rare, and wasn't really relevant here. I can't think of any situation where hardlinks to directories are preferable. Deven -- shadow@[128.113.10.2] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.