Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!clyde!burl!codas!novavax!murphy!dave From: dave@murphy.UUCP (Dave Cornutt) Newsgroups: comp.unix.wizards Subject: Re: Symbolic Links Message-ID: <621@murphy.UUCP> Date: Fri, 25-Sep-87 09:25:57 EDT Article-I.D.: murphy.621 Posted: Fri Sep 25 09:25:57 1987 Date-Received: Sun, 27-Sep-87 11:53:25 EDT References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <3728@elecvax.eecs.unsw.oz> Organization: Gould CSD, Fort Lauderdale, FL Lines: 88 Summary: an example of useful non-tree-strucutred directories In article <3728@elecvax.eecs.unsw.oz>, neilb@elecvax.eecs.unsw.oz (Neil F. Brown) writes: > The thrust of my arguement is - do you ever really want to have a directory > in two different places? i.e. with two different absolute path names that > don't include the well-understood (I thought) `.' and `..'. > If you don't, then generalised mounting will solve your problems. I have at least one case right here. I have a program which uses include files and object modules from another program which is rather large. I don't want to make copies of the files I need because (1) I don't want to have to keep up with updates to these files, which are not under my control, and (2) they are too large to have multiple copies laying around; contrary to the claims of some small-system advocates, just because you have an 800M drive to play with doesn't mean you waste space keeping 30 copies of everything around when a simple alternative -- symlinks -- are available. So, I have one link to the include directory of this program, and another to the object directory. Sometimes I need to switch to a different version of the program, to keep up with updates or just to try an experiment -- no problem; I just move the links. This way, I can get access to the things without having to make copies, and without having to impose my idea of directory structure on the person who maintains this program. Occasionally I cd through one of these links to have a look around. Funny, but I never really thought about "cd .." taking me back to my directory, and I'm not sure that I'd even want it to do that. Reason is, these directories that my links point to are in the middle of a heirarchy, and sometimes I want to go look at other places in that structure, so I expect "cd .." to take me up a level in that heirarchy, not back to my directory. So, how *do* I get back to my directory? Well, pushd/popd solves the problem for me -- a shell mechanism, with no kernel trying to do me favors that, in this case, I don't want. It reminds me of the story about the Boy Scout who was determined to help a little old lady across the street, even if he had to drag her, kicking and screaming. > There are two sub-cases for this question: > 1/ Public directories, > 2/ Private directories. I think the above was a useful example of (2). I can think of other examples that might fit either category: (a) a third-party program that you don't have the source to that has a pathname hard-coded into it (we have one here), (b) moving critical software packages to another file system temporarily if you lose a drive or to make space for something else, and (c) relocating parts of the system that everyone "knows" is supposed to be in a certain place. The best example of this is the /usr-/pub division on diskless-machine servers, which may be serving several types of machines. We have another example on our system: vi and the vi recovery utility expect the path to the preserve directory to be /usr/spool/preserve. We don't have enough space on /usr for it (some of our users edit files of >2M), and we don't have a disk partition available to mount it on. No problem; we just move it to the /usr/spool filesystem and leave a symlink in /usr, and vi is none the wiser. To sum up, symlinks are a fairly simple way of doing things that you can't easily do otherwise, and they cause few security complications, so I can't understand why some people are so anxious to throw them away. I'd much rather have a system where I can move things around without upsetting programs (and people) than a system that conforms to some ideological filesystem purity where I can't move things around. I've found that most users can readily grasp the concept of symlinks if someone who has both knowledge and patience just sits down with them for a few minutes and explains it to them. I remember working on an old Data General RDOS system which had symlinks and being impressed with what a simple-but- powerful concept it was, and how frustated I got back in my V7 days because it didn't have symlinks. Yes, you can create spaghetti file systems with them, but you can also write spaghetti code in C, and I don't see anyone screaming for a major overhaul of C just because a few poor programmers can't deal with it. After all, flexibility and customization are the name of the game in UNIX. I think the generalized-mount idea is worth pursuing (didn't V6 have something like this?), but not as a replacement for symlinks. I also like David Korn's idea of the retained cd path for handlind symlinks to directories, but I want it to be able to turn it on and off; I don't want to be browbeaten into using it. I'm pretty sure that our customers would not accept changes or elimination of symlink being shoved down their throats. --- "I dare you to play this record" -- Ebn-Ozn Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL [Ignore header, mail to these addresses] UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt ARPA: dcornutt@gswd-vms.arpa "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."