page%swap@Sun.COM (Bob Page) (06/27/89)
[This really belongs someplace else. Followups to comp.sys.amiga.] >Anybody out there want to suggest a half-dozen or so uses for a soft link? Why a half-dozen? I would think one good use would be enough justification (you define "good"). I'll tell you why I use them (all the time, in fact). Because I can never remember where I put everything. If I have a document "foo" on a particular device, I might put it in doc/dev/foo ... or I might put it in dev/doc/foo. I don't want to remember where it is, I want the computer to remember for me. So I link doc/dev and dev/doc to be the same thing. Similarly for things like docs==doc and the like. From day to day I can't remember if my Amiga music directory is music/amiga or amiga/music or even amiga/audio, so I link them all together and forget about it. Another common use (for me) is to have different names for files. For example, util-v1, util-v2, util-v3 util linked to util-v2 This may seem trivial but it can be a real time-saver when you're debugging. Especially here at work where I have access to machines of different architectures, I can soft link files and directories to things like bin -> bin/sun3 and I get the right binaries by referring to 'bin'. Another use is to name one program differently based on what you want to use it for. For instance, Matt Dillon's 'backup' and 'restore' programs are the exact same code. Same with 'compress' and 'uncompress'. They know how to act based on what they are called. If you don't have links, you have to duplicate the code on the disk, so you might have two 100K files, one for compress and one for uncompress. If you have links you link them together and you're only taking 100K (plus the link overhead but that's not worth including). On the Amiga, I can think of an immediate need. I have some programs that need large data files, and they go seeking around in the data files often. One particular application, which I can't recompile, *demands* that the data files and associated utilities it calls be in the "current directory". I could just copy the whole directory to RAM:, but I don't have enough RAM to do that. In this case, I can copy just the large data file to the RAM disk, and link the name in the "current directory" to the data file in RAM. Now my application runs a lot faster because the data file is on the RAM disk, although the application program doesn't know (or care). Anyway, that's what I use links for, off the top of my head. Probably more too. > And maybe a few for a hard link? Hard links and soft (or symbolic) links are just different implementations of the same idea under UNIX, each with its own strengths and limitations. Under the Amiga FS in the non-existant v1.4, all links are soft links. However, UNIX-heads have come to think of soft links as being able to cross file systems, and the FS links under the non-existant v1.4 don't. So there's some effort to provide a cross-filesystem link "above" FFS, somewhere at the DOS level. This may or may not happen. And of course I'm making this up because v1.4 doesn't exist. > I can think of some trivial uses but what do you really need 'em for? You don't REALLY need them. They are a convenience. And that's what computers are all about, eh? ..bob
page%swap@Sun.COM (Bob Page) (06/27/89)
In addition to the uses for links I posted, there's one important one I forgot. When your disk partition is full and you *have* to get that one last directory into FONTS: before your whizzy application will work, you can put the new directory on another partition and provide a link to it in the FONTS: directory. Poof, instant disk space. There are probably more uses I'm forgetting, but you might be getting the idea that links can be useful. In almost every case you can provide workarounds but none are as quick or elegant as what you achieve with links. ..bob
doug@xdos.UUCP (Doug Merritt) (06/27/89)
In article <112459@sun.Eng.Sun.COM> page@sun.UUCP (Bob Page) writes: >[This really belongs someplace else. Followups to comp.sys.amiga.] Disagree. Technical issues are involved, the only reason to avoid .tech would be the assumption that all .tech'ies are Unix-heads who know all about links, which ain't true. I've been wanting to talk about how links *should* be implemented on the Amiga, and why, ever since I found out that "the obvious way of doing it" isn't the way that certain people are planning an experimental implementation. >Another use is to name one program differently based on what you want >to use it for. For instance, Matt Dillon's 'backup' and 'restore' >programs are the exact same code. Same with 'compress' and >'uncompress'. They know how to act based on what they are called. If >you don't have links, you have to duplicate the code on the disk, so >you might have two 100K files, one for compress and one for uncompress. >If you have links you link them together and you're only taking 100K >(plus the link overhead but that's not worth including). This is a very important usage. Other examples: 'vi' is linked to 'ex' is linked to 'edit' is linked to 'view'. Also 'zcat' is linked to 'compress' and 'uncompress' (and I keep wanting to do this particular example on my Amiga). Another usage, somewhat similar to some you cited, is to put the file name (link) wherever convenient, but to put the massive body of the file onto whichever disk has sufficient space. Thus I experimentally compile somebody's 50 megabyte source in my own local directory, using a link to point at the source to avoid copying it, and can avoid overwriting the results of *their* compilation. Naturally most people don't have to deal with such large source, but the principle applies in general. Similarly I set up Usenet news on a free 100 Meg disk partition, and by providing appropriate links, it appears as though it is set up on everybody's own local file system. (This can also be accomplished by rmounting, but much less flexibly.) Note that the latter applications require cross-device links. >Hard links and soft (or symbolic) links are just different >implementations of the same idea under UNIX, each with its own >strengths and limitations. Under the Amiga FS in the non-existant >v1.4, all links are soft links. However, UNIX-heads have come to >think of soft links as being able to cross file systems, and the FS >links under the non-existant v1.4 don't. So there's some effort to >provide a cross-filesystem link "above" FFS, somewhere at the DOS >level. This may or may not happen. And of course I'm making this up >because v1.4 doesn't exist. This is the same old story we've been dealing with for the last decade. Unix has its problems, but it also has some really superlative strengths (Berkeley Unix, anyway). And every time some other OS adopts a *subset* of the features, the incompleteness always turns out to be an annoyance to those who've gotten used to the conveniences of Unix features. Ten years ago I was writing Unix utilities (more, diff, grep, etc) for CPM to bridge the convenience gap. Now it's a question of what kinds of links, etc. To me it's obvious that "subset" isn't good enough. When can I have a system that has a *superset* of the features of Unix??? There's a clear need for both hard and soft links, and someone who hasn't used both kinds in the past probably won't clearly understand why, but that doesn't make it less true. In fact there's a clear need for other kinds of links, too, e.g. to support hypermedia-ish tools. Active links that trigger servers, for instance, which I designed into a circa '82 mainframe OS, but which still aren't generally available in any mainstream OS. At least Unix V.4 will have a process FS, again an old concept but not one being considered for AmigaDos yet. The Mac pioneered resource forks years ago, and while they have their problems, they provide some minimal functionality that any OS designer should be taking very very seriously today. The lack of resources in AmigaDos is a real shame (right, Chuck? :-). Two steps forward, and one back. The reason that the state of the art of software is so primitive even now is that people are always aiming towards a minimally justifiable set of features instead of looking forward to a maximally generalized set of features. Sigh. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
elg@killer.DALLAS.TX.US (Eric Green) (06/30/89)
From article <392@xdos.UUCP>, by doug@xdos.UUCP (Doug Merritt):
$>Hard links and soft (or symbolic) links are just different
$>implementations of the same idea under UNIX, each with its own
$>strengths and limitations. Under the Amiga FS in the non-existant
$>v1.4, all links are soft links. However, UNIX-heads have come to
$>think of soft links as being able to cross file systems, and the FS
$>links under the non-existant v1.4 don't. So there's some effort to
$>provide a cross-filesystem link "above" FFS, somewhere at the DOS
$>level.
$ There's a clear need for both hard and soft links, and someone who hasn't
$ used both kinds in the past probably won't clearly understand why,
The problem is that there is a seperate file system process for each
mounted device on the Amiga, Doug, so it's hard to do cross-device
links (all that DOS is, for the most part, is a converter that turns
your requests into messages to send to the Dos-handler or filesystem).
As for hard links -- in Unix terms, the filename is in the inode under
AmigaDOS. That means you'd have to put the filename somewhere else if
you wanted hard links. That sounds pretty reasonable, actually, if you
stop to think that one of AmigaDOS's biggest problems is pulling up a
directory out of all these scattered "inodes"... unfortunately, the
only DOS routine to pull out filenames from a directory under <=1.3 is
ExNext, which requires one to pull in the complete FIB. Hopefully
that's something that'll be added under later versions of AmigaDOS --
ways of getting filenames out of a directory without pulling in the
entire FIB.
Needless to say, such a filesystem would be totally different from the
current filesystem, whereas soft links can be plugged into the current
filesystems with little trouble.
$ least Unix V.4 will have a process FS, again an old concept but not one
$ being considered for AmigaDos yet.
Are you saying that under Unix V.4 that filesystems run as a process?
That's been true from the earliest versions of AmigaDOS... it's
inherent in the entire system. All that dos.library does is turn your
requests into packets to send (via Exec message-passing) to DOS
handler processes (which may or may not be a file system). See Toebes
& Walker's excellent articles in the last 2 issues of AmiTransactor
for more info.
Of course, under Unix V.4 each filesystem will have only a single
process, while under AmigaDOS each mounted device has a filesystem
process... but I don't want to second-guess the tradeoffs between the
two approaches.
--
Eric Lee Green P.O. Box 92191, Lafayette, LA 70509
..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849
"I have seen or heard 'designer of the 68000' attached to so many names that
I can only guess that the 68000 was produced by Cecil B. DeMille." -- Bcasedillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (06/30/89)
:
:$ There's a clear need for both hard and soft links, and someone who hasn't
:$ used both kinds in the past probably won't clearly understand why,
:
:The problem is that there is a seperate file system process for each
:mounted device on the Amiga, Doug, so it's hard to do cross-device
:links (all that DOS is, for the most part, is a converter that turns
:your requests into messages to send to the Dos-handler or filesystem).
As one who has fooled around with filesystems a bit this is not
difficult to do. The only really sticky part with file handler processes
is how to deal with ExNext(), and this doesn't come up when you implement
soft links.
Routing DOS request packets between filesystem processes is easy.
From using soft links and hard links in UNIX systems it is clear that
soft links are much more useful.
:As for hard links -- in Unix terms, the filename is in the inode under
:AmigaDOS. That means you'd have to put the filename somewhere else if
:you wanted hard links. That sounds pretty reasonable, actually, if you
The problem with hard links on the Amiga is that the filename is
part of the file header (the 'inode'). On UNIX systems the filename
is part of the directory entry and not associated with the inode.
Thus, however hard links are implemented on the Amiga it will be a
big hack. I strongly suggest to C-A that they forget hard links
entirely and implement softlinks (which they can do in a day).
: Eric Lee Green P.O. Box 92191, Lafayette, LA 70509
-Mattdoug@xdos.UUCP (Doug Merritt) (06/30/89)
In article <8489@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: >The problem is that there is a seperate file system process for each >mounted device on the Amiga, Doug, so it's hard to do cross-device links [...] >Needless to say, such a filesystem would be totally different from the >current filesystem, whereas soft links can be plugged into the current >filesystems with little trouble. True. But let's call that an implementation detail. :-) >$ least Unix V.4 will have a process FS, again an old concept but not one >$ being considered for AmigaDos yet. > >Are you saying that under Unix V.4 that filesystems run as a process? >That's been true from the earliest versions of AmigaDOS... it's No, I mean that processes will have entries in the file system. The idea being that the generalization of a file system is that it's a name space that can be conveniently used to find data, and "pointers" to processes are a handy thing to find there, too. Just like it's been handy that Unix has always had file system entries for kernel memory, user process memory, physical devices, etc, in addition to "regular files". Mach, on the other hand, has user-installable file system servers, somewhat like AmigaDOS. >Of course, under Unix V.4 each filesystem will have only a single >process, while under AmigaDOS each mounted device has a filesystem >process... but I don't want to second-guess the tradeoffs between the >two approaches. I don't understand your comment, probably because I don't know what V.4 provides in this area. Perhaps you mean that V.4 has a process per filesystem, which is to say per logical device (disk partition), whereas AmigaDOS has a task per physical device? Hmmm, no, not true of AmigaDOS, you can mix slow and fast file systems on a single disk. Care to clarify? Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
cosell@bbn.com (Bernie Cosell) (07/01/89)
In article <8906300334.AA12228@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: }: }:$ There's a clear need for both hard and soft links, and someone who hasn't }:$ used both kinds in the past probably won't clearly understand why, }: } } From using soft links and hard links in UNIX systems it is clear that } soft links are much more useful. Foo. "much more useful" is clearly in the eye of the beholder: soft links and hard links are DIFFERENT, they have virtually nothing to do with one another, and neither can do the job of the other. One links a name to a file-object in a way that is *fully* symmetric with all other names linked to that file-object, and the other maps a name in the file system into another name. That is, one is name->file, the other is name->name. VERY DIFFERENT stuff. I agree with the original statement: there is a CLEAR need for both. That we might not be able to have both in a particular filesystem due to some design decisions that were made long ago is unfortunate. I happen to think that the Amiga will end up with the less-useful kind. Although I admit *many* otherwise pretty sharp folk seem to be almost-completely baffled by how hard links work (that they are not, really, 'links' in the same sense that a softlink is a link). What's interesting (to me at least) is that the confusion usually results in folks thinking: (a) that the two kinds of links are sort-of the same thing, and so use them indiscrimately without understanding what they are doing (generally, they either learn to type "ln" or "ln -s" and never really have a clue what they're doing in either case). (b) they ascribe to this "link" operation some odd set of qualities which turns out to be something of a blend of the properties of the two, and so whenever anything even slightly out-of-norm happens they're guaranteed to be surprised (e.g., they can NEVER remember (and surely cannot figure out!) what happens when they "rm <hardlink>" versus "rm <softlink>" }:As for hard links -- in Unix terms, the filename is in the inode under }:AmigaDOS. That means you'd have to put the filename somewhere else if }:you wanted hard links. } } The problem with hard links on the Amiga is that the filename is } part of the file header (the 'inode'). On UNIX systems the filename } is part of the directory entry and not associated with the inode. } } Thus, however hard links are implemented on the Amiga it will be a } big hack. I strongly suggest to C-A that they forget hard links } entirely and implement softlinks (which they can do in a day). To argue that it is *easier* to do without hard links in AmigaDOS is fine (and I agree, as if that's worth anything :-)). Unfortunately, I suspect that if you can only have one, hardlinks are the more useful one. In fact, for all practical purposes you can *simulate* the semantics of softlinks in application software if you have hardlinks (I like softlinks plenty and use them a lot, but we got along just fine without them for a long time, and it was no big deal: as I say, when we needed softlink semantics it was easy to implement. If you're only going to have one kind of link, at least shoot for the one which is powerful enough to give you the effect of BOTH kinds. [and expanding on my comment above, when unix ONLY had hard links, generally users fairly quickly figured it out, even the really-slow ones... now that unix has both, almost EVERYONE that hasn't done any kernel hacking gets confused... and it is usually because *softlinks* have semantics that they don't expect (generally when the file softlinked-to changes or goes away or moves and they find out about it when something breaks in an odd way -- one of the one that KILL 'em is when their softlink in turn points at a softlink (unbeknownst to them) and it is a hop hidden insde someone *else's* hierarchy that went away)). And, the constant darkside of softlinks turns up over and over again: there is the constant confusion about 'rm'... Very few folks have a strong enough intuition about the differences between the two types of links to be confident about what rm does on each (and find and tar, etc). And again, the confusion is almost always at the doorstep of softlinks into play: with "hardlinks" there is complete symmetry. There is no "original file" versus the "link", and so the operations are easy to understand. The asymmetry in softlinks (between the file and the softlink to it) means that there will ALWAYS be confusion about what will happen for any given operation: SOME have to act on the link, itself, SOME have to act on the file, itself, and it is REAL hard to get confident about which do which... But, given that AmigaDOS _does_ have the file names (in essence) _in_ the files, you're probably right: taking a half-day to hack in softlinks relatively cleanly is lots better effort expended than in fighting to kludge hardlinks into a scheme to which it is clearly not amenable. Unfortunately, I think we differ in that I think that this expediency will leave us Amiga-folk with the lesser of the two bits of machinery. /Bernie\
limonce@pilot.njin.net (Tom Limoncelli) (07/02/89)
Ring! Ring! Hello, I'd like to make an observation? In article <42236@bbn.COM> cosell@bbn.com (Bernie Cosell) writes: [much deleted] > ...... Although I admit *many* otherwise > pretty sharp folk seem to be almost-completely baffled by how hard links work > (that they are not, really, 'links' in the same sense that a softlink is a > link). What's interesting (to me at least) is that the confusion usually > results in folks thinking: [ two examples of how users often get confused by the existance of more than one kind of link ] If hardlinks and softlinks are both needed, but their semantics are difficult to remember by most people, then wouldn't it be a good place for one command to do both but let the computer decide which to use? That way it is transparent, but the proper one is used*. Any program that has to deal with links just knows that there are two cases it must be ready to deal with. Basically, this abstracts the two needs into one concept. It also follows the laws "let the computer decide what it can decide better than the user" and "similar things should be dealt with similarly". But, there is no clean way to implement one kind of link. So maybe it should be left as "unimplemented" but structure the commands around the fact that it could be added at any moment. Of course, for all we know that code has been frozen and the way it will be in 1.4 is the way it will be. Tom Footnote * -- Of course, in Unix everyone wants to be closer to the machine so it's two different things. Since AmigaDOS is supposed to be friendlier this "all-in-1" concept fits a little better there. ...and of course, there could be override flags on the commands. -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University