jdp@caleb.UUCP (Jim Pritchett) (06/06/89)
This is yet another 1.4 request. Could file links be added? How difficult
would this be?
--
Jim Pritchett
UUCP: {killer|texbell}!letni!caleb!jdp
or killer!gtmvax!dms3b1!caleb!jdpmcp@ziebmef.uucp (Marc Plumb) (06/17/89)
In article <0933.AA0933@caleb> jdp@caleb.UUCP (Jim Pritchett) writes: >This is yet another 1.4 request. Could file links be added? How difficult >would this be? I know this is being worked on, both hard and soft, but there are tricky bits. Suppose /bin/vi and /bin/ex are links to the same file. I Lock() vi, then Examine() the lock. Which name gets returned? Does the file comment go with the name (so vi and ex could have different comments) or the file (so they'd have the same)? Also, there is the bit that's nasty for directory-scanning speed, in that you now have to store the name in one place and the file-specific information (size, date, etc.) in another, and read both places when returning a FileInfoBlock. Then there's the business of allowing files with no links, and do you allow directories with multiple links, etc. I have a solution to some of these problems, by saying that a Lock is not a file, it's a pathname to a file. You can move the path (so /bin/vi can get moved to /usr/ucb/vi) without breaking it, and Examine() and ParentDir() will tell you that's the name of the current lock, without bothering you with /bin/ex. A file can have no links, if it's only referenced through a FileHandle and not a Lock, and it will do the normal Unix thing of being deleted on close. BTW, all this would require serious hacking to the Commodore-supplied file systems. I think they'd end up being rewritten. I've asked before, but does anyone here have any opinions on The Right Way to provide these features? -- -Colin Plumb
FelineGrace@cup.portal.com (Dana B Bourgeois) (06/19/89)
As a favor to those of us who are opinionated but but a bit ignorant, could some kind soul define in 25 words or less what a lock, handle, path, hard link, and soft link are? I can guess but it would be a case of a little knowledge being dangerous. Thanks in advance. Email would be OK this is not of general interest. Dana
peter@sugar.hackercorp.com (Peter da Silva) (06/23/89)
In article <1989Jun16.151408.8382@ziebmef.uucp>, mcp@ziebmef.uucp (Marc Plumb) writes: > In article <0933.AA0933@caleb> jdp@caleb.UUCP (Jim Pritchett) writes: > >This is yet another 1.4 request. Could file links be added? How difficult > >would this be? > I've asked before, but does anyone here have any opinions on The Right Way > to provide these features? Hard links wouldn't be worth it, given the way Examine and ExNext work. Soft links would be easy... you would just store the new file name in the comment feild. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
FelineGrace@cup.portal.com (Dana B Bourgeois) (06/25/89)
Ok, Peter. I've studied up and asked questions and I think I have a pretty good idea of what a hard link and a soft link is. But what am I gonna *do* with a soft link once they become available? Anybody out there want to suggest a half-dozen or so uses for a soft link? And maybe a few for a hard link? I can think of some trivial uses but what do you really need 'em for? Dana (thankx)
new@udel.EDU (Darren New) (06/27/89)
In article <3940@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1989Jun16.151408.8382@ziebmef.uucp>, mcp@ziebmef.uucp (Marc Plumb) writes: >> In article <0933.AA0933@caleb> jdp@caleb.UUCP (Jim Pritchett) writes: >> >This is yet another 1.4 request. Could file links be added? How difficult >Hard links wouldn't be worth it, given the way Examine and ExNext work. Soft >links would be easy... you would just store the new file name in the comment >feild. Even better, leave the comment field alone and store the new name in the list of blocks the file uses. But since we probably want to not make the name so short, we (royal we) would use both the block list and the comment field and the date and the protection bits, possibly overflowing into actual data blocks. As hard disks and networks get larger, restricting file names to 80 characters could be a problem. Now what happens if ExNext runs across a soft link to something on a non-mounted volume? Do we prompt the user to put in that volume, or what? Say it is on the same volume: how does ExNext tell the user it is a soft link without breaking existing software? I would suspect that most directory scanners either say IF directory-block THEN xxx ELSE yyy; or IF regular-file THEN yyy ELSE xxx; Adding a new case could cause lots of problems. Of course, we could always change ExNext to look for the linked-to file and make NewExNext return more status information. But then what happens when the soft-link and the linked-to file are in the same directory? We wind up seeing and maybe trying to delete the same file twice? Should a Lock on a soft-link file actually lock the linked-to file also? If not, won't opennng the file twice cause problems? If so, what if we really want to lock the soft-link? I think this is not quite so easy as it seems. (It never is, is it? :-) -- Darren (good at finding problems, lousy at fixing them) New a problem.
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (06/27/89)
In article <19856@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
<Anybody out there want to suggest a half-dozen or so uses for a
<soft link? And maybe a few for a hard link? I can think of some
<trivial uses but what do you really need 'em for?
First, a quick non-technical definition of hard & soft links. Hard
links are two names for the same file. Soft links are a reference to a
file elsewhere. To keep from turning your directory tree into a graph,
hard links aren't permitted to directories. Likewise, by their very
nature, you can't put them on different file systems (it's implicit in
the concept of name).
Now, let's look at some uses.
I keep several collections of data around - picture, sounds, brushes,
etc. Now, several of the programs I use that manipulate these things
cause file requesters to open in some fixed location, usually relative
to where they are. This means I need to put all those utilities in the
same tree as the data files, some in the directory above them, some in
the directory with them. This is a pain. Of course, I still haven't
solved the problem of some looking for one directory name, and others
looking for another.
Given soft links, I can put them wherever I please (like on the fast
disk I set aside for current projects), leave the binaries where I
want them (on a seperate spindle), and create symlinks where needed to
the data directories. Soft links ar required for directories.
I'm not sure why Peter thinks hard links have advantages over soft
links. They have different semantincs under cp/rm/mv, which may make
them more appropriate in some cases. On the other hand, I consider
different semantics to be a problem, not a feature. He'll have to
explain that one himself.
<mike
--
And then I saw her... Mike Meyer
She was a bright red '64 GTO mwm@berkeley.edu
With fins and gills like some giant piranha fish, ucbvax!mwm
Some obscene phallic symbol on wheels. mwm@ucbjade.BITNETprotcoop@bnr-public.uucp (Joel Avery) (06/27/89)
I am not sure of what a hard or soft link is as you speak of them I refer here to links per the UNIX 'ln' command. My prof at school used to keep all of our assignments in a file that we would link to. Without the link, we would have to type a >20 character path/filename. The links eliminated this bother. --------------------- Alan W. McKay | My opinions are mine, yours are yours. | Eat Food | NEPEAN, Ont. | I in no way pretend to represent the | and | 613-763-8980 | the options of my employer. So there. | LIVE !! |
peter@sugar.hackercorp.com (Peter da Silva) (06/28/89)
In article <19856@cup.portal.com>, FelineGrace@cup.portal.com (Dana B Bourgeois) writes: > Ok, Peter. I've studied up and asked questions and I think I have > a pretty good idea of what a hard link and a soft link is. But > what am I gonna *do* with a soft link once they become available? These can be hard or soft: link c:ls c:list Now your aliaes work in execute scripts. link sys:system/preferences c:preferences Now you don't have to put sys:system in your path. These have to be soft: link devs:system-configuration workbench:devs/system-configuration Now you don't to copy system-configuration back to df0: when you have a hard disk that doesn't autoboot. link :Disk.info rad:Disk.info Now all your disk icons look the same. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
peter@sugar.hackercorp.com (Peter da Silva) (06/28/89)
In article <18529@louie.udel.EDU>, new@udel.EDU (Darren New) writes: > Even better, leave the comment field alone and store the new name in the > list of blocks the file uses. But since we probably want to not make the > name so short, we (royal we) would use both the block list and the comment > field and the date and the protection bits. Yes. > actual data blocks. No. Let's keep soft links small. One block. > ExNext runs across a soft link to something on a non-mounted volume? > Do we prompt the user to put in that volume, or what? Yes. > Say it is on > the same volume: how does ExNext tell the user it is a soft link > without breaking existing software? It magically turns on a 'link bit' in the protection flags (and magically turns it off if it's not a link). > always change ExNext to look for the linked-to file and make NewExNext > return more status information. Yes. This is implicit in the idea of links. What to do with the file name portion of the feild is interesting... magically turn it into the name of the link or not? I think yes, to avoid confusing directory searchers. But if you lock it and examine the lock, then you'd get the real name (and no transparent link bit). You just need an NewExNext that *doesn't* follow the link and returns the new structure if it is a linke. > But then what happens when the soft-link > and the linked-to file are in the same directory? We wind up seeing and > maybe trying to delete the same file twice? Depends on just what we do, but in general, yes. > Should a Lock on a soft-link > file actually lock the linked-to file also? Yes. > If so, what if we really want to lock > the soft-link? I can't think of a reason for this, offhand. > I think this is not quite so easy as it seems. (It never is, is it? :-) But it's not as complex as it seems. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
peter@sugar.hackercorp.com (Peter da Silva) (06/28/89)
Hard links are "better" than soft links because you can't delete the linked-to file accidentally and suddenly have a bunch of non-existent files around to confuse the hell out of utility programs. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (06/29/89)
In article <3960@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: <In article <18529@louie.udel.EDU>, new@udel.EDU (Darren New) writes: <> always change ExNext to look for the linked-to file and make NewExNext <> return more status information. < <Yes. This is implicit in the idea of links. What to do with the file name <portion of the feild is interesting... magically turn it into the name <of the link or not? I think yes, to avoid confusing directory searchers. First, you don't need a NewExNext. Just have ExNext check the magic link bit when it comes to a link. If the bit is on (set by the user), it just hands back the link block, which contains nothing but the file name and the name of the file it's a link to. If the bit is off (which it should be for all current binaries), it gets a FileInfoBlock for the file the link points to, and then plugs the name from the link FIB into the new one, and hands that back to the user. <> But then what happens when the soft-link <> and the linked-to file are in the same directory? We wind up seeing and <> maybe trying to delete the same file twice? < <Depends on just what we do, but in general, yes. That is the way things should behave. If you've got two copies of the same file in a directory now, you see them twice. The same should apply to links. <> I think this is not quite so easy as it seems. (It never is, is it? :-) < <But it's not as complex as it seems. I haven't seen anybody mention fixing the utilities to match this. That's going to make things harder. Especially if the default behavior is to follow the link. First rule: _everything_ that determines it's got a link should report where it's a link to. I.e. - instead of saying "this is a link", they should all say "this is a link to <name>". You quickly get annoyed at utilities that don't do that. Second rule: the default behavior for things that walk the file system tree must be chosen carefully (thought experience dictates that not following links is usually correct). If it follows links, it must keep a stack of all the directories it's currently visiting, and check to make sure it's not going to revisit one of those (this is why not following links is usually correct). In addition, each such utility must be carefully examined to see if it makes sense to add an option to do the other thing with links (the answer is usually "yes"), and deal with that. [Side note: anyone feel up to writing the ftw routine & tw program for the Amiga? It'd make life a lot nicer!] Third rule: Backup/restore programs must be made to undestand links, and deal with them properly. Unless you timestamp the link, this means saving a copy of the link (not the file it points to) every time. This is just a disk block or two, so that's no big deal. Remember, you're introducing a new file type into the system. Every program that looks at a files type must be made to deal with this type. You also have to make sure that the default behavior doesn't make existing programs die in strange ways. Now, Peter - care to define the default behavior so that my rprot (recursive protect - changes permissions on a tree) program won't 1) get upset when it finds a file that's not a directory or data file, and 2) won't die for lack of stack space if I feed it a tree with a link back to the top of the tree? Now, on users being able to delete things out from under soft links. That doesn't confuse the applications: they just find they can't open files. A "list" on the file (gotta check the permissions, ya'know) should show it's a soft link to a file that doesn't exist. On the flip side, hard links make it possible to "update" a file, and not have everyone using the updated version - because they have hard links to the original. All you have to do is delete or rename the old version before copying the new version into place. Soft links don't have that problem - they refer to a file by name, so when you open the symlink, you always get whatever file has that name. This more than makes up for the ability to delete a file without mentioning it by name. <mike -- Kiss me with your mouth. Mike Meyer Your love is better than wine. mwm@berkeley.edu But wine is all I have. ucbvax!mwm Will your love ever be mine? mwm@ucbjade.BITNET
lee@sed170.HAC.COM (John Lee ) (06/30/89)
In article <19856@cup.portal.com> you write: [...] >Anybody out there want to suggest a half-dozen or so uses for a >soft link? And maybe a few for a hard link? I can think of some >trivial uses but what do you really need 'em for? > >Dana > >(thankx) I have a use for soft-links I use almost every day. My current project involves the X11 Toolkit and the header files every module requires resides in /usr/include/X11, so that #includes look like: #include <X11/another_header.h> I'm developing widgets, so I'm constantly creating/deleting/modifying these header files, so I have them in my own subdirectory ~/wrk/X11. Since the "<>" format means the directory /usr/include, the #includes I use look like: #include "X11/another_header.h" which will look in /usr/include after looking at my directory first, so even if the header is in /usr/include/X11, things still work. Still with me? Good. Here's where soft-links are absolutely necessary: Because of the object-oriented hierchy of the toolkit, most of those headers need to include other headers in the X11 directory. That means that I must have a soft-link in ~/wrk/X11 to itself. Without it, I would need to know and manually include the headers for every object above the object I'm dealing with in the hierchy and it would be a *BIG* mess or even impossible. But that's not all. Soft-links allows a file to appear in multiple directories yet when a change in the file is needed, only the actual files needs to be updated--the links are updated "automatically". One can also restrict access such that links can only read the file and not write to it. While this doesn't appear particularly useful, it's very handy on a multi-user machine where multiple programmers need to share files but have each file changeable by only one person. Programmers don't have to hardcode full paths for each file in another person's directory. They just link to the file in the foreign directory and use it as if it were in their (sub)directory. It's useful for team projects and classes. It's not too hard to envision similar situations for a user or programmer on an Amiga, and the above are by no means a complete list. ------------------------------------------------------------------------------- Raining CATS and DOGS? Join the RATS: Remote Amiga Teleconferencing System +--------+ John Lee | HUGHES | +--------+ ARPAnet: jhlee@hac2arpa.hac.com Hughes Aircraft Company The above opinions are those of the user and not of those of this machine.
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (06/30/89)
:Hard links are "better" than soft links because you can't delete the :linked-to file accidentally and suddenly have a bunch of non-existent :files around to confuse the hell out of utility programs. :-- :Peter "Have you hugged your wolf today" da Silva `-_-' What ? That's really funny. Soft links are better than hard links period. * Removing a softlink removes the softlink, NOT the file it is pointing to * You can create soft links to non existant (or not yet existant) paths * You can have soft links across filesystems * You can have soft links to devices * It doesn't require any hacking on low level FS structures 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!). * 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. * hardlinks cannot cross device boundries and you cannot hard link something that does not exist yet. You can only hard link real honest to goodness files. * Hardlinks look like normal files or directories... all the more confusing. -Matt
doug@xdos.UUCP (Doug Merritt) (06/30/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. 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 everyone to see when and whether the file body should be deleted. Or in practice forgetting about it, everybody deletes their soft links, and the file needlessly takes up disk space. Although this can come up with a single person & multiple projects, clearly it is more likely to in a multiuser environment. But since we can safely assume that Amiga's will never be used in such environments, like LANs, we can ignore this, eh? :-) > * 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 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. > * It doesn't require any hacking on low level FS structures Implementation detail. > 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. > * 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.) > * 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. 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 P.S. I'm ignoring the limited exceptions to the rule that you can't hardlink to Unix directories because those exceptions don't seem important in this context. -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
doug@xdos.UUCP (Doug Merritt) (07/01/89)
I said: >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. I neglected to explain more fully. The fact that hard links reference- count the file and delete it when there are no more hard links left can be handy for the same reasons that automatic garbage collection of unused data structures is handy in languages. As in languages, GC of files can save tedious and error prone manual housekeeping. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
jesup@cbmvax.UUCP (Randell Jesup) (07/01/89)
In article <25860@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >I haven't seen anybody mention fixing the utilities to match this. >That's going to make things harder. Especially if the default behavior >is to follow the link. Yes, links will cause some programs (mostly utilities, such as dir/ls/etc, backup programs, search, and a few others) to rev to deal with links. Most programs shouldn't care. >First rule: _everything_ that determines it's got a link should report >where it's a link to. I.e. - instead of saying "this is a link", they >should all say "this is a link to <name>". You quickly get annoyed at >utilities that don't do that. Quite true: this applies mostly to dir/ls/list programs. > [Side note: anyone feel up to writing the ftw routine >& tw program for the Amiga? It'd make life a lot nicer!] ftw I know, and shouldn't be hard to do (plus it'll be useful for our own programs - or at least something like it). What is tw? (I assume it stands for tree-walk, but my sun has no man entry for it.) >Third rule: Backup/restore programs must be made to undestand links, >and deal with them properly. Unless you timestamp the link, this means >saving a copy of the link (not the file it points to) every time. This >is just a disk block or two, so that's no big deal. I suspect soft links will have timestamps. >Now, Peter - care to define the default behavior so that my rprot >(recursive protect - changes permissions on a tree) program won't 1) >get upset when it finds a file that's not a directory or data file, >and 2) won't die for lack of stack space if I feed it a tree with a >link back to the top of the tree? Any recursive fs-walk in a program should have stack checking built in (yes, I know dir doesn't now, but it will). As for non-directory non- file entries, you won't see them unless you understand links (you'll see what they point to). If you understand links, you're ok. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
jesup@cbmvax.UUCP (Randell Jesup) (07/01/89)
In article <398@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >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. To totally delete a hardlinked file, you must delete all the links/ files. To totally delete a soft-linked file, you must delete all the softlinks and the original file(link). Plus I don't see what these times you reference are. >> * 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. >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 >everyone to see when and whether the file body should be deleted. Or in >practice forgetting about it, everybody deletes their soft links, and >the file needlessly takes up disk space. Getting a complaint on a non-existant destination when linking is easy. As for your "multi-user" example, this may occur, but not often in my experience in multi-user and workstation Unixes (in fact, I've never felt any need for a hardlink, but I've often used softlinks - every day, in fact). >> * 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 >require a second path search to find the real inode. So far it seems >to me that the same could be true on AmigaDos. Hard links are faster, true, but they're considerably less flexible. Also, I don't see the speed diferential as being bad (AmigaDos already dos better than most unixes by having hashed directories, which are fast at finding a specific entry). >> * It doesn't require any hacking on low level FS structures > >Implementation detail. Yeah, but a real nasty one. >> 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. Not when they mean an extra month or two of work for us, plus a slew of new bugs to weed out (FFS/OFS is getting rather crufty already, in trying to support things it wasn't designed to, especially since the same handler must deal with OFS disks, and write OFS disks that can be read by 1.3 machines - no disk format changes). >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. And because unix backup programs explicitly ignore softlinks. >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 True, but we may not be able to support that under AmigaDos hard links, even if we do them, simply because the design of the FS doesn't make it easy. Plus, I think the shell should remember how you got where you are, so cd'ing up one level will make it subtract 1 level from the previous string for current directory, then CD there. (cd /foo/bar/zed, where zed is softlinked to /bar/foo/zed. The shell would remember /foo/bar/zed as your current dir. Then you cd .., and it removes zed from /foo/bar/zed, leaving /foo/bar, and cd's to there.) Also, how often do you cd to a hard-link on unix? :-) -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/01/89)
In article <7187@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: <In article <25860@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: <> [Side note: anyone feel up to writing the ftw routine <>& tw program for the Amiga? It'd make life a lot nicer!] < < ftw I know, and shouldn't be hard to do (plus it'll be useful for <our own programs - or at least something like it). What is tw? (I assume <it stands for tree-walk, but my sun has no man entry for it.) That was a slip - I meant ftwalk, not ftw. Ftwalk does the same kind of things as ftw, except that it provides more flexibility. It's also faster than most of the roll-your-own file tree walkers in Unix commands. Tw is a tool based on ftw, that gives you an awk-like langauge for dealing with each file; looking at it's stat structure, and those of it's parent and other files. See the June '89 Usenix proceedings for a description of both. < Any recursive fs-walk in a program should have stack checking <built in (yes, I know dir doesn't now, but it will). As for non-directory non- <file entries, you won't see them unless you understand links (you'll see <what they point to). If you understand links, you're ok. All true - but it's just barely more acceptable for a program to complain about being out of space & die than it is for it to GURU the machine. Can I assume that all utilities that walk trees will understand links, and do the "right" thing (where "right" varies with the utility)? And that users will be warned that creating circles in their file tree could create problems for older programs? <mike -- Round about, round about, in a fair ring-a. Mike Meyer Thus we dance, thus we dance, and thus we sing-a. mwm@berkeley.edu Trip and go, to and fro, over this green-a. ucbvax!mwm All about, in and out, over this green-a. mwm@ucbjade.BITNET
doug@xdos.UUCP (Doug Merritt) (07/01/89)
In article <7190@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > To totally delete a hardlinked file, you must delete all the links/ >files. To totally delete a soft-linked file, you must delete all the softlinks >and the original file(link). I missed this difference in semantics between (potential) AmigaDOS soft links and Unix soft links (symbolic links). On Unix, the file goes away as soon as you delete the "real" file, regardless of any remaining softlinks to it. Deleting soft links never does anything to the original file. >> [ ...I dismissed implementation "details"...] > Not when they mean an extra month or two of work for us, plus a slew >of new bugs to weed out (FFS/OFS is getting rather crufty already, in trying >to support things it wasn't designed to, especially since the same handler >must deal with OFS disks, and write OFS disks that can be read by 1.3 >machines - no disk format changes). I certainly sympathize. I just think it's appropriate to settle the question of whether something is desirable under ideal circumstances first, and *then* look at when. And the answer might be "don't hold your breath", but at least it'd be known that the issue *was* desirable. Or not. So far there doesn't seem to be much agreement. >>I hate to do "cd directory; cd .." and discover that I haven't returned >>to where I started. This never happens with hard links. > [...] Plus, I think the shell should remember how you got where you are, >so cd'ing up one level will make it subtract 1 level from the previous string >for current directory, then CD there. (cd /foo/bar/zed, where zed is >softlinked to /bar/foo/zed. The shell would remember /foo/bar/zed as your >current dir. Then you cd .., and it removes zed from /foo/bar/zed, leaving >/foo/bar, and cd's to there.) Yeah, that's probably the best possible way to fix it. The fact that such difficulties arise at all clearly comes about from the fact that a purely hierarchical file system isn't quite powerful enough, but current state of the art doesn't have the ideal solution to how to handle a file system which is a graph. I think that this points in the right direction, though, and the problem will be explored in more detail as people get more familiarity with the issue of navigating complexly structured hypermedia documents. > Also, how often do you cd to a hard-link on unix? :-) Ouch. Got me there. I was inconsistent. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
peter@sugar.hackercorp.com (Peter da Silva) (07/02/89)
I said, speaking of UNIX links: > :Hard links are "better" than soft links because you can't delete the > :linked-to file accidentally and suddenly have a bunch of non-existent > :files around to confuse the hell out of utility programs. Matt Dillon thought I was speaking of Amiga links. I will agree that in no circumstances should hard links be implemented on an Amiga file system. They just won't work. But just in case people get confused... In article <8906300342.AA12274@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Soft links are better than hard links period. Sorry, I can't agree. The main difference is that hard links are all peers. This has advantages and disadvantages, true, but... > * Removing a softlink removes the softlink, NOT the file it is pointing > to Removing a hard link removes the link, not the file it is pointing to. When you remove the last hard link the file is reclaimed. This is useful when you need to give a file a number of names, with no name having priority. This is an advantage of hard links... removing the "original" doesn't leav the other links in the lurch. > * You can create soft links to non existant (or not yet existant) paths Yes. This is an advantage of symbolic links. > * You can have soft links across filesystems Yes. This is an advantage of symbolic links. > * You can have soft links to devices You can have hard links to devices, too. > * It doesn't require any hacking on low level FS structures Popping back one level, symbolic links require some FS hacking. You need to stick the name somewhere. I guess you could put it *in* the file... > 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!). Hard links with UNIX semantics aren't supportable at all. > * 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. How do backup programs deal with soft links? You could set up a bunch of files that seem to have more data in them than the whole disk can hold. A backup program would have to know about links in either case. > * Hardlinks look like normal files or directories... all the more > confusing. In any way that a link *doesn't* look like a normal file or directory it's a disadvantage. I would hope that, unless you do something special, soft links also look like normal files and directories. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
peter@sugar.hackercorp.com (Peter da Silva) (07/02/89)
In article <25860@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > In article <3960@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > <In article <18529@louie.udel.EDU>, new@udel.EDU (Darren New) writes: > <> always change ExNext to look for the linked-to file and make NewExNext > <> return more status information. > <Yes. This is implicit in the idea of links. What to do with the file name > <portion of the feild is interesting... magically turn it into the name > <of the link or not? I think yes, to avoid confusing directory searchers. > First, you don't need a NewExNext. Just have ExNext check the magic > link bit when it comes to a link. If the bit is off (which > it should be for all current binaries... It took me a second to figure out that the magic link bit refers to. It's something attached to the program, or in the ExNext call. How does this differ from having two ExNexts? (ExNext and ExNextLink, if the name NewExNext offends) > First rule: _everything_ that determines it's got a link should report > where it's a link to. Yes. > Second rule: the default behavior for things that walk the file system > tree must be chosen carefully (thought experience dictates that not > following links is usually correct). Yes. > Third rule: Backup/restore programs must be made to undestand links, Yes. > Now, Peter - care to define the default behavior so that my rprot > (recursive protect - changes permissions on a tree) program won't 1) > get upset when it finds a file that's not a directory or data file, > and 2) won't die for lack of stack space if I feed it a tree with a > link back to the top of the tree? By default, call ExNext(..., GIMME_LINKS) or ExNextLink(). That is, don't follow links. Old programs may be broken by links... I know Browser will be. This is not a reason not to implement them... just don't put any on the distribution disks, or ship programs that depend on them for a while. > Now, on users being able to delete things out from under soft links. > That doesn't confuse the applications: they just find they can't open > files. A "list" on the file (gotta check the permissions, ya'know) > should show it's a soft link to a file that doesn't exist. That's the best solution, and shouldn't cause problems except for people who don't use the CLI. Which is quite a few people. But they're unlikely to be using links anyway. > On the flip side, hard links make it possible to "update" a file, and > not have everyone using the updated version - because they have hard > links to the original. Only if the editor they're using has brain-damaged backup semantics. And sometimes it's an advantage to be able to break the link. But not in AmigaDOS. -- 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/02/89)
FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >Ok, Peter. I've studied up and asked questions and I think I have >a pretty good idea of what a hard link and a soft link is. But >what am I gonna *do* with a soft link once they become available? > >Anybody out there want to suggest a half-dozen or so uses for a >soft link? And maybe a few for a hard link? I can think of some >trivial uses but what do you really need 'em for? > >Dana > >(thankx) Suppose you had five disks of fonts... You could link them all together, and it would look like only one big disk to programs that can't support multiple font directories (Lik ProWrite), and the system would ask you to swap disks for it. (Soft Links) What's an example for hard links? Opps, gotta change my .signature... The BBS is not up anymore... _ _ | \ _ ___ _ | \ _ | _ 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!
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/03/89)
In article <3973@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: <In article <25860@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: <> First, you don't need a NewExNext. Just have ExNext check the magic <> link bit when it comes to a link. If the bit is off (which <> it should be for all current binaries... < <It took me a second to figure out that the magic link bit refers to. It's <something attached to the program, or in the ExNext call. How does this differ <from having two ExNexts? (ExNext and ExNextLink, if the name NewExNext offends) Sorry 'bout that, that was badly written. It's the same bit in the FileInfoBlock that you use to determine if something is a link or not. After using the FileInfoBlock, and just before calling ExNext, you turn it on. ExNext notices it. This makes the OS cleaner (IMHO - but I'm disgusted by BSD's plethora of calls to do the same thing, and multiple levels of compatability and "old" calls, so my view is biased). The people who actually write ExNext/links will have to decided which way is better in their view, and do it that way. <> Now, Peter - care to define the default behavior so that my rprot <> (recursive protect - changes permissions on a tree) program won't 1) <> get upset when it finds a file that's not a directory or data file, <> and 2) won't die for lack of stack space if I feed it a tree with a <> link back to the top of the tree? < <By default, call ExNext(..., GIMME_LINKS) or ExNextLink(). That is, <don't follow links. < <Old programs may be broken by links... I know Browser will be. This is <not a reason not to implement them... just don't put any on the distribution <disks, or ship programs that depend on them for a while. The point is that it's not really acceptable to break old programs. On the other hand, there may not be much choice about it. The trick is to break as few as possible. <> On the flip side, hard links make it possible to "update" a file, and <> not have everyone using the updated version - because they have hard <> links to the original. < <Only if the editor they're using has brain-damaged backup semantics. Uh, what editor? Consider: rename c:mycom c:mycom.old copy mycom c:mycom Viola, things are broken. Of course, you could do a copy/clone instead of a rename, but that takes more time - so you have to do everything the hard way, or know the file is linked to. The first is unacceptable. The second means it doesn't matter whether the link is hard or soft; you know about it and so can be expected to deal with it. BTW, without hard links, using anything other than "brain-damaged" (I assume you mean "rename" instead of "copy", as those are what break) backup semantics is silly. Considering how rare hard links are even on systems that support them, it's still pretty silly. <mike -- Il brilgue: les toves lubricilleux Mike Meyer Se gyrent en vrillant dans le guave, mwm@berkeley.edu Enmimes sont les gougebosqueux, ucbvax!mwm Et le momerade horsgrave. mwm@ucbjade.BITNET
FelineGrace@cup.portal.com (Dana B Bourgeois) (07/03/89)
I think I started all this talk about links. The discussion has been great. I've learned alot about files, directories, and links. I thought all of the contributors would be interested to know that having read all your comments and thought about what I do on my machine and how links work, I can see a good half dozen very very NON-trivial uses for links both hard and soft. If one of you would post a hacked up version of the file system that included soft links then Boy Howdy! I'm ready to use it! Dana "If ya keep on doin whatcha always done, Y'll keep on gitten whatcha always got" - placard at a local craft fair.
jesup@cbmvax.UUCP (Randell Jesup) (07/04/89)
In article <402@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >In article <7190@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >> To totally delete a hardlinked file, you must delete all the links/ >>files. To totally delete a soft-linked file, you must delete all the softlinks >>and the original file(link). > >I missed this difference in semantics between (potential) AmigaDOS >soft links and Unix soft links (symbolic links). On Unix, the file goes >away as soon as you delete the "real" file, regardless of any remaining >softlinks to it. Deleting soft links never does anything to the original file. Sorry, I misunderstood what you were asking. I thought you were saying that all the softlinks (themselves) went away when the file they point to goes away (in Unix), which is not the case. Currently, Amiga softlinks will work like Unix softlinks. Most probable implementation is as a file with the "softlink" protection bit set, and the file containing the string for the link, unless I can figure a way to worm it into the header (for short strings). The nice thing about this is that existing filesystems will magically support softlinks with no new packets, at the expense slightly slower opens/locks, since the fileheader must be retrieved to check the bits. However, the file header block almost certainly will be cached at that point, since it's needed to lock the file. (The Dos manual lies when it says locks are much cheaper than opens. :-) Opinions? (ducking from the avalanche of c.s.a.t messages :-) -- Randell Jesup, Commodore Engineering. Keeper of AmigaDos. {uunet|rutgers}!cbmvax!jesup Common phrase heard at Amiga Devcon '89: "It's in there!"
peter@sugar.hackercorp.com (Peter da Silva) (07/04/89)
In article <25963@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > In article <3973@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > <Old programs may be broken by links... I know Browser will be. This is > <not a reason not to implement them... just don't put any on the distribution > <disks, or ship programs that depend on them for a while. > The point is that it's not really acceptable to break old programs. On > the other hand, there may not be much choice about it. The trick is to > break as few as possible. Sorry, but it *is* acceptable to break old programs. If you have to break old programs to provide more functionality, then it's not just acceptable, it's required. Otherwise you end up with something like MS-DOS. Old programs broke when people started putting more than 512K in their Amigas, when they put in 68010s and 68020s, when 1.2 came out, when 1.3 came out, when the A500 came out, when the A2000 came out, when ExtraHalfBright was shipped, when people put hard disks in their Amigas, and so on. Microsoft refused to break old programs, and now MS-DOS is so encrusted with crud that they're having to throw the whole thing out and start over. They did better with Xenix, though we're still having to use a System-III based version because they don't have a SysV version for our hardware... they kept upgrading the SysIII until now they've forced a major break instead of a gradual upgrade. 1.4 will break stuff. 1.5 will break stuff. In 2.0 they get to break everything :->. Back to the point. When I say "old programs will be broken", I'm talking about a few old programs (ones that do tree-walks), and there will be a simple workaround (don't do directory links up the tree). And no matter how you implement links, backup and directory-listing programs will have to be updated. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
addison@pollux.usc.edu (Richard Addison) (07/07/89)
In article <3959@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <19856@cup.portal.com>, FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >> Ok, Peter. I've studied up and asked questions and I think I have >> a pretty good idea of what a hard link and a soft link is. But >> what am I gonna *do* with a soft link once they become available? >... >These have to be soft: > >link devs:system-configuration workbench:devs/system-configuration > > Now you don't to copy system-configuration back to df0: > when you have a hard disk that doesn't autoboot. Unfortunately, AmigaDOS will try to access devs:system-configuration through the workbench:devs/system-configuration link _BEFORE_ you have a chance to mount your harddisk. Nice idea, though. I am curious: how will soft links be handled from workbench? I imagine that there will be an additional menu item to create them and I suppose that the INFO menu item will identify soft linked files. However, will there be any visual indication in an icon for a soft link? Will soft links be chased down before workbench creates the startup message for a workbench application? (I suppose that depends on whether you can put a lock on a soft link or not.) What if 'foo.info' is a soft link, but 'foo' isn't? Or vice versa? >Peter "Have you hugged your wolf today" da Silva `-_-' >...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` Richard "Do you know where your sheep are" Addison < u u > o
peter@sugar.hackercorp.com (Peter da Silva) (07/09/89)
In article <18304@usc.edu>, addison@pollux.usc.edu (Richard Addison) writes: > In article <3959@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >link devs:system-configuration workbench:devs/system-configuration > > Now you don't to copy system-configuration back to df0: > > when you have a hard disk that doesn't autoboot. > Unfortunately, AmigaDOS will try to access devs:system-configuration through > the workbench:devs/system-configuration link _BEFORE_ you have a chance to > mount your harddisk. Nice idea, though. You have it backwards. When you boot from the floopy, devs:system-configuration is workbench:system-configuration. Then you mount dh0:, and typically assign all your devices to dh0:. So now devs:system-configuration is in dh0:devs. If you softlink that file back to the original workbench:system-configuration it'll get correctly saved on workkbench:, rather than dh0:. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`