dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (07/01/89)
: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
shadow@pawl.rpi.edu (Deven T. Corzine) (07/01/89)
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] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
doug@xdos.UUCP (Doug Merritt) (07/01/89)
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
papa@pollux.usc.edu (Marco Papa) (07/01/89)
After the recent flurry of messages about "hardlinks vs. softlinks" let me give my 5 cents: * If CBM has to chose between including hardlinks and softlinks for 1.4, it is clear that softlinks should be chosen: they are CLEARLY easier to implement, and seem to be enough for 99% of the cases. * In 8 years of work managing UNIX systems, I have used hardlinks once or twice, probably at the beginning. In my daily use, softlinks suffice to do all that I need (personal experience, of course). * I would really be *MAD* if, because of the introduction of 'hardlinks' and the sure MAJOR changes to AmigaDOS, release of 1.4 is further delayed by the 2-3 months of extra development/testing which has been proposed as a possible ballpack figure for it. Note that my opinions are heavilly BIASED by the fact that as a commercial developer I'd like to see 1.4 out ASAP, no matter how well anybody can convince me of the benefits of hard links. I'll entertain any personal e-mail, so as to lower the bandwidth. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
doug@xdos.UUCP (Doug Merritt) (07/01/89)
In article <18191@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >* If CBM has to chose between including hardlinks and softlinks for 1.4, it > is clear that softlinks should be chosen: they are CLEARLY easier to > implement, and seem to be enough for 99% of the cases. Well, when you put it *that* way, yes, definitely, absolutely agree! Perhaps we should have changed the subject to be "1.5 request" to avoid implying otherwise. >* In 8 years of work managing UNIX systems, I have used hardlinks once > or twice, probably at the beginning. In my daily use, softlinks suffice to > do all that I need (personal experience, of course). This supports your point about "give me soft links soon rather than delaying everything for the sake of hard links". But naturally it doesn't answer whether hard links are ever useful; in terms of that, it amounts to "I don't know of a use; do you?" which is being addressed elsewhere. Although I'm playing devil's advocate, I would agree that, of the two, Unix symbolic links are far more *generally* useful than Unix hard links, if I had to pick one of the two. But the discussion is useful in pointing out exactly which semantics are useful, and which are not. It appears that AmigaDOS softlinks may differ significantly from Unix symbolic links, so this is a good thing to explore. Recall my original concern: at the "Beyond 1.4" talk, someone in the CBM section of the audience said that AmigaDOS hard links would allow links to directories, and said Unix was bad for not allowing that. To me, that meant we'd better start discussing the issues! I don't think that links are so obvious that discussion of their intricacies is a waste of time. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (07/02/89)
: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 >-- >
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/02/89)
In article <401@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
<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.
Hey, I like that. Only I'd just make it one flag: "ln -c file file2".
<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,
This is the first thing I've seen that points in what I consider the
right direction. Hard links & soft links have a large area of overlap
when it comes to actual use. It'd be nice to find a single concept
that covers everything.
<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.
And then, when <someone> edits tmp.c, they overwrite (depending on the
editor) your link with something that no longer triggers the bug. Of
course, soft links do the same thing.
Also, you can only do this thing on small systems. Large systems tend
to have users files scattered around multiple disks - so you have to
use a soft link if you still want to use a link.
<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.
Hey, Doug - where did you get the virtual reality?
True, I don't have hard links to directories on any of my current
systems. But that's because they all support soft links. On systems
that didn't have soft links (ah, the days when Unix was fast on submip
machines), I made hard links to directories. I'd do it again under the
same circumstances.
On the other hand, I knew what I was doing, and used that ability
carefully. I'm _very_ glad T & R took it away from everday users
before I got to Unix.
Along the same lines, someone said that people don't create soft links
to files. This is equally false - I do. Usually when I want a single
command from someones private bin, want to make sure I always have the
latest version, and don't want to spend the space on it. Soft links
are the only way to do that. Of course, I lose when the file is
deleted, but that's better than losing when it's updated.
Of course, on the system I work on most of the time, we have users on
13 file systems. So odds are 12-1 that I won't be able to make a hard
link to files in a random users directory anyway.
What I'm curious about is why this fascination with doing thing the
way Unix did them? Just because Unix was the first popular OS to do
links doesn't mean it did them right - in fact, being first means it
probably did them wrong. As has been pointed out here, hard & soft
links both have problems. To me, something that sits in the middle
would be much better. Oddly enough, AmigaDOS has that; there's just no
way to put a lock into the file name space. So how about adding it,
like so:
1) Creating a link basically creates a soft link, except it also bumps
the link count for the file it's linked to.
2) Opening a link causes a lock to the original file to be saved,
which you can now get to via the link name. This should work much like
an automatic assign, or a "link cache." (Hmm - on second thought, this
doesn't seem like such a good idea. I'll leave it here anyway.)
3) You can't delete or rename a file unless it's link count is zero.
4) Creating a link to a link chases down the real file, uses it's name
and bumps it's link, all so
5) You can always delete or rename a link.
First note: this shouldn't be a lot harder than doing Unix-style soft
links - except for the cache...
Second note: The default behavior of link is to fail if there isn't an
original file; it's got to bump a link count. It ought to be possible
to force a link to a nonexistent file. Such things should result in
failure if opened.
Third note: Making links go "through" links is to get more of the hard
link semantics into the links. It also menas you never have to chase
through multiple links (or, worse yet, backwards through multiple
links).
Fourth note: not being able to rename is the key. This is where the
difference between hard and soft links really becomes apparent. Hard
links aren't affected by the rename. Soft links are. Both behaviors
can be confusing/desirable at times. So I claim that the behavior of
not permitting it to happen is correct - you make whoever is doing the
rename find & deal with the files that are linked to the original as
is apropriate for them. That way, you don't get any unexpected effects
(either old copies still floating around, or open failures in the
future).
Fifth note: a tool needs to be provided for dealing with all the links
of a file during a rename.
Sixth note - and I just realized it: dealing with links from
demountable volumes is going to be a bitch.
I realize this is all so much hot air; 1.4 links could already be set
in stone, so nobody who matters will be listening.
Sigh,
<mike
--
And then up spoke his own dear wife, Mike Meyer
Never heard to speak so free. mwm@berkeley.edu
"I'd rather a kiss from dead Matty's lips, ucbvax!mwm
Than you or your finery." mwm@ucbjade.BITNETmwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/02/89)
Oh yeah - second note on the locklinks (for lack of a better name) I just proposed. It might be nice to be able to specify that the file linked to is to be executed with the rest of the path name (plus data about the type of access wanted by the opener) as an argument, and it will return a lock to be handed to the opener. Of course, that's probably just a pipe dream. <mike -- Es brillig war. Die schlichte Toven Mike Meyer Wirrten und wimmelten in Waben; mwm@berkeley.edu Und aller-mumsige Burggoven ucbvax!mwm Die mohmem Rath' ausgraben. mwm@ucbjade.BITNET
toebes@sas.UUCP (John Toebes) (07/05/89)
In article <18191@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >After the recent flurry of messages about "hardlinks vs. softlinks" let me >give my 5 cents: > >* If CBM has to chose between including hardlinks and softlinks for 1.4, it > is clear that softlinks should be chosen: they are CLEARLY easier to > implement, and seem to be enough for 99% of the cases. >-- Marco Papa 'Doc' I hate to pop your bubble on this, but from the standpoint of writing an AmigaDos filing system (and experience to back it :-) softlinks are *SIGNIFICANTLY* more difficult to implement than hardlinks. With softlinks, the file system needs to be able to communicate with other filing systems *ASYNCHRONOUSLY*. This is an important point because of the problem where a file may be linked to another device which in turn is a link back to a different place on the original device. We haven't even started to scratch the surface of handling details such as links from filesystems to handlers which support a subset of packet types or even worse handling any newly defined packets. Look at how long it took Bill Hawes to get Pathman correct - there are many loopholes to be handled and some subtle interactions. Hardlinks on the otherhand, while certainly less flexible, do not require any external access by a handler. Yes, there are conceptual problems to deal with in terms of Examine() and recovering space when deleting entries not to mention deleting the base object without deleting all links. Un*x solves this problem by making all file entries links to the inode that describes the object and keeping a reference count in the inode. Certainly there are ways that we can make this work but it is not trivial. At a minimum we are talking a solid month of work including testing of all the obscure situations (like deleting the linked object in the middle of two ExNext() sequences) to put in hard links. To implement softlinks I would put that estimate between 2 and 3 months because of all the interactions of handlers and the potential for reving other handlers. One alternative that might be faster to implement (which may be what you are thinking about when you described it as easier) would be to implement soft links which do NOT work across volumes. This solves reference counts and the obscure situations. However, I suspect that this would draw flames from people who feel that this is a poor job because it is "CLEARLY easy to implement it correctly to work across devices". If I had my vote (which I don't) in this issue, I would opt for implementing ... NOTHING ... I don't think that the feature is worth the effort that could be better spent on other parts of AmigaDos to get 1.4 out sooner. But then again, the above is only my opinion. You are welcome to implement a file system and compare experiences. I know there is some experience out there now. -- |0|\ John A. Toebes, VIII usenet:..mcnc!rti!sas!toebes |.|/ Coordinator of The Software Distillery BBS: (919)-471-6436 === Bix: JTOEBES Plink: JTOEBES CI$:"sorry Charlie"
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (07/06/89)
In article <8907012203.AA21545@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > 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. Hey Matt, what about your backup and restore program? Same executable, changes behavior depending on the name--that seems like a prime candidate for a soft link to a file. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
peter@sugar.hackercorp.com (Peter da Silva) (07/06/89)
In article <1092@sas.UUCP>, toebes@sas.UUCP (John Toebes) writes: > With softlinks, the file system needs to be able to communicate with other > filing systems *ASYNCHRONOUSLY*. Only if you're requiring that softlinks have full UNIX symbolic link semantics. I understand that's not considered a requirement in the first release. Also, if you implement the links in dos.library the whole problem goes away. Of course duplicating namei() in dos.library is a bit of a performance hog... how about this: if a handler sees a soft link it returns a flag that says "this is a soft link", the contents of the link, and the rest of the file. dos.library would call DeviceProc on the new link and cons up the new name, passing it to the new handler. No recursion in the file systems, at the cost of requiring people to use dos.library to get hold of files... do.library is opverdue for a complete rewrite anyway. And hardlinks are only easier if you don't require full UNIX semantics, which is a bit unfair. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (07/06/89)
:In article <8907012203.AA21545@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
:> 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.
:
:Hey Matt, what about your backup and restore program? Same executable,
:changes behavior depending on the name--that seems like a prime candidate
:for a soft link to a file.
:
:-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
:-Wilson Lab, Cornell U.
Absolutely true. But how many programs are like that?
compress-uncompress
backup-restore
maybe one or two others.... not very many. These are one time
things too. So if you take it in perspective about 90% of
my soft links would be directories. On the amiga there would
be more reason to soft link files (say, fonts and commercial
libraries so I can keep stuff bundled with the rest of its
associated software).
-Mattdillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (07/06/89)
:In article <18191@usc.edu> papa@pollux.usc.edu (Marco Papa) writes:
:>After the recent flurry of messages about "hardlinks vs. softlinks" let me
:>give my 5 cents:
:>
:>* If CBM has to chose between including hardlinks and softlinks for 1.4, it
:> is clear that softlinks should be chosen: they are CLEARLY easier to
:> implement, and seem to be enough for 99% of the cases.
:>-- Marco Papa 'Doc'
:
:I hate to pop your bubble on this, but from the standpoint of writing an
:AmigaDos filing system (and experience to back it :-) softlinks are
:*SIGNIFICANTLY* more difficult to implement than hardlinks. With
:softlinks, the file system needs to be able to communicate with other
:filing systems *ASYNCHRONOUSLY*. This is an important point because
I thought of it. It turns out that in all the cases I could
think of you would simply ROUTE the packet to the -other- handler...
you would NOT have to deal with any responses from the other handler, it
would respond directly back to the user process (or route the packet
again, etc...).
This would require on that the *Arg? (any argument in the packet
which holds a filename) to be a static buffer which can be modified...
*extremely* easy to do since we are buffered by library routines.
:Look at how long it took Bill Hawes to get Pathman correct - there are
:many loopholes to be handled and some subtle interactions.
That was a different problem... he had to deal with ExNext()
didn't he? Totally different. Examine()/ExNext() was never implemented
correctly in the first place.. you didn't know when the user process
was done ExNext()ing.
:At a minimum we are talking a solid month of work including testing of
:all the obscure situations (like deleting the linked object in the middle
:of two ExNext() sequences) to put in hard links. To implement softlinks
:I would put that estimate between 2 and 3 months because of all the
:interactions of handlers and the potential for reving other handlers.
For a hard link or a softlink? For a softlink at least there
is no problem... you are simply deleting the softlink itself just
like a normal file. I think this goes for a hardlink too, maybe...
not sure.
:--
: |0|\ John A. Toebes, VIII usenet:..mcnc!rti!sas!toebes
: |.|/ Coordinator of The Software Distillery BBS: (919)-471-6436
: === Bix: JTOEBES Plink: JTOEBES CI$:"sorry Charlie"
-Mattmwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/06/89)
<:Hey Matt, what about your backup and restore program? Same executable, <:changes behavior depending on the name--that seems like a prime candidate <:for a soft link to a file. < < Absolutely true. But how many programs are like that? < < compress-uncompress < backup-restore < < maybe one or two others.... not very many. I can think of three others (on Unix - it's sorta silly to count them on a system that doesnt' have links) off the top of my head: ex-vi-edit csh--sh-a.out (hmm - make it four: sh--sh also) rsh-/usr/hosts < So if you take it in perspective about 90% of < my soft links would be directories. On the amiga there would < be more reason to soft link files (say, fonts and commercial < libraries so I can keep stuff bundled with the rest of its < associated software). Your soft links only? My personal links split about 70-30 the other way. On the other hand, system wide (on my systems), there are _far_ more links to files (whether soft or hard) than links to directories. There are over 1700 in /usr/hosts alone. <mike -- The handbrake penetrates your thigh. Mike Meyer A tear of petrol is in your eye. mwm@berkeley.edu Quick, let's make love before we die. ucbvax!mwm On warm leatherette. mwm@ucbjade.BITNET
jesup@cbmvax.UUCP (Randell Jesup) (07/07/89)
In article <1092@sas.UUCP> toebes@sas.UUCP (John Toebes) writes: >I hate to pop your bubble on this, but from the standpoint of writing an >AmigaDos filing system (and experience to back it :-) softlinks are >*SIGNIFICANTLY* more difficult to implement than hardlinks. With >softlinks, the file system needs to be able to communicate with other >filing systems *ASYNCHRONOUSLY*. This is an important point because >of the problem where a file may be linked to another device which in >turn is a link back to a different place on the original device. We >haven't even started to scratch the surface of handling details such >as links from filesystems to handlers which support a subset of packet >types or even worse handling any newly defined packets. John is making an incorrect assumption here: that soft links will be implemented by the filesystems. What is planned is for the dos library to implement them (note that this may have some gotchas for people using packet interfaces right now, depending on how we implement it). There are two obvious ways to implement links: one with files with a link bit set, the other using a couple of new packets to deal with links and opening files. Both will affect asych packet io people (if they Lock/Open using asych - Read/Write/etc won't be affected); one requires no modification to filesystems (and therefor can be used on OFS floppies, over NFS, etc immediately), the other is a bit more robust in dealing with asynch IO and old dir/delete/etc programs. Comments? >Look at how long it took Bill Hawes to get Pathman correct - there are >many loopholes to be handled and some subtle interactions. One reason we don't plan on having a path-handler ala Bill's in 1.4. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
ddave@pnet02.cts.com (David Donley) (07/07/89)
Why not make "Soft-SoftLinks"? Have a command like assign that will let you assign an entire path to another. Whenever the dos.library saw one of these comming through, it could expand it. No handler/aplication changes needed! Wouldn't slow anything down. Bug Eyes is dead, I'll make a new signature one day. _ _ | \ _ ___ _ | \ _ | _ Call THE Bug Eyes BBS at (213) 372-4494. |_//-\\/_|_|_) |_/(_)/\/||_-\/ Life is too short for copy-protection- ^[33m^[41mANSI is my life!^[m/ and should be even shorter for pirates! Send mail to: ddave@pnet02.CTS.COM or killer!gryphon!pnet02!ddave NO FLAMES!
peter@sugar.hackercorp.com (Peter da Silva) (07/09/89)
In article <17422@gryphon.COM>, ddave@pnet02.cts.com (David Donley) writes: > Why not make "Soft-SoftLinks"? Have a command like assign that will let you > assign an entire path to another. Whenever the dos.library saw one of these > comming through, it could expand it. No handler/aplication changes needed! > Wouldn't slow anything down. Intel's OpenNET implements this under Xenix. It calls them redirects. They are in every way inferior to symbolic links. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
ddave@pnet02.cts.com (David Donley) (07/12/89)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <17422@gryphon.COM>, ddave@pnet02.cts.com (David Donley) writes: >> Why not make "Soft-SoftLinks"? Have a command like assign that will let you >> assign an entire path to another. Whenever the dos.library saw one of these >> comming through, it could expand it. No handler/aplication changes needed! >> Wouldn't slow anything down. > >Intel's OpenNET implements this under Xenix. It calls them redirects. They are >in every way inferior to symbolic links. Could you be a little bit more specific?
peter@sugar.hackercorp.com (Peter da Silva) (07/14/89)
In article <17573@gryphon.COM>, ddave@pnet02.cts.com (David Donley) writes: > peter@sugar.hackercorp.com (Peter da Silva) writes: > >Intel's OpenNET implements this under Xenix. It calls them redirects. They > >are in every way inferior to symbolic links. > Could you be a little bit more specific? % df / (/dev/dsk/0s1 ): 10 blocks 2517 i-nodes /usr (/dev/dsk/1s3 ): 3878 blocks 11565 i-nodes /usr1 (/dev/dsk/0s3 ): 11996 blocks 11367 i-nodes % du /tmp 45 . % rdr /tmp /usr1/tmp % du /tmp 0 . % something_that_chews_up_lots_of_space % du /tmp 1636 . % cd / % du tmp 45 . When the fs sees "/tmp" at the beginning of a string it textually replaces it with the string "/usr1/tmp". It has to be the exact string (cd /; du tmp had a different effect), it has to be dynamically created (as opposed to symlinks, which are non-volatile), and it involves a table-look-up on every file open. Symbolic links are much cleaner. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`