Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP Newsgroups: comp.unix.wizards Subject: Re: Symbolic links Message-ID: <892@mcgill-vision.UUCP> Date: Sat, 19-Sep-87 18:18:39 EDT Article-I.D.: mcgill-v.892 Posted: Sat Sep 19 18:18:39 1987 Date-Received: Sun, 27-Sep-87 23:04:15 EDT References: <3711@elecvax.eecs.unsw.oz> Organization: McGill University, Montreal Lines: 150 In article <3711@elecvax.eecs.unsw.oz>, neilb@elecvax.eecs.unsw.oz (Neil F. Brown) writes: > It occurs to me that there is a very simple way to avoid the problems > with symbolic links. It is to not have symbolic links to > directories. Back when what we now call hard links were the only kind of link, they were allowed to refer to directories. Now, they technically still are, but hard links to directories may be created only by root, and are strongly deprecated in any case. These wonderful new things, symbolic links, were brought around to be used when you wanted a link to a directory. > [this can be done. just have namei() fail.] > However, this restriction is not really needed, just have ln complain > if the target is a directory (or if the target doesn't exist??), Not sufficient. % mv /foo/bar /foo/bar- % touch /foo/bar % ln -s /foo/bar /baz % rm /foo/bar % mv /foo/bar- /foo/bar > "But", you say, "We LIKE sym links to directories, we need them, life > was so bland and colourless before we found them." > I think not. Consider the apparent `uses' for symlinks to > directories. > 1/ The most commonly mentioned directory symlink seems to be > /usr/include/sys -> /usr/sys/h > This, to me, is a bad thing. The kernel include files should be > in ONE place and one place only. This is why the symlink: rather than having two copies, one on /sys/h and the other on /usr/include/sys, we have just one, with the other pointing to it. The files need to be present in /usr/include/sys so they can be found with and they need to appear under /sys so that all kernel source is logically together. (You seem to believe they should be in /sys/h so that all of /sys is on the same filesystem. Irrelevant, say I. Who cares what disk /sys/h is on in relation to /sys/sys or /sys/whatever? What matters is that it all appears under /sys, where all the rest of the kernel source is.) > (Further, [/usr/include] should be the home directory of user `i' > so users only need use ~i.) Where in the world did you come up with that? Really now, how often do you want to access /usr/include from the cshell? > 3/ I remember long ago (1 month?) someone suggested symlinks were > terribly useful for moving around a large tree. Link interesting > directories to X and then put X in your cdpath so interesting > places can be found quickly from anywhere. > I have a better solution, set up some shell variables > S=/somewhere/sources B=/overthere/binaries X=/my/favourite/place > then just use cd $X/whatever. Go fly a kite. The only sense in which this is "better" is that it allows you to get rid of symlinks to directories. From my point of view, it is actually worse because it requires more typing. > 4/ [...] > 5/ Vast numbers of other apparent uses that are simply "wrong" or > could better be fixed by [other means] Example: I have two source directories for some program, one for our VAXen and one for our Suns. This is because (a) this way there is no confusion of .o files and (b) the sources are slightly different. One of these has most of the source files symlinked to the other, but that's irrelevant - those are just links to files. However, I find that when working on the VAX version I often want to look at some file in the Sun directory and vice versa. So in the VAX source directory I create a symlink "sun" pointing to the Sun source directory and in the Sun directory I create a symlink "vax" pointing to the VAX source directory. This way I can just visit sun/sun-foo.c when working on the VAX side, and similarly when working on the Sun version. What would you say is the "right" way to do this? It won't work to create environment variables "sun" and "vax" and visit $sun/sun-foo.c, even assuming my editor groks environment variables, because that means I have to change the environment every time I start working on another program - the symlinks for programA don't bother me when I'm messing with programB. We can't use your generalized mount because that would make each machine lose its own directory tree. In fact, we could never complete both mounts at once! Example: I am working on a program which is kept in its own directory somewhere. This program meshes with some kernel support, which I am also working on. So in the program source directory I make a symlink "sys" pointing to the directory with the kernel portions, so I can access the kernel pieces with short, easy-to-type names. Same problems as above. Example: /usr/doc/ps1/13.rcs/man is a symlink pointing to /usr/src/new/rcs/man. Clearly the contents of this directory (yes, it is a directory) should appear both places - you can't weasel out the way you tried to with /usr/include/sys. What do we do? This is also true of several other documentation directories. Example: /sys/machine is a symlink to "vax" or "sun3" or whatever, as appropriate for the machine in question. What should we replace this with? Example: We use NFS to export filesystems around. We mount machine foo on /@foo. For uniformity (pathnames can use "/@machine/..." regardless), machine foo itself has a symlink "/@foo" pointing to ".". What do we replace this with? Enough examples. Onward.... > The generalised mount. > The mount function links inode I of block device B to inode 1 (the Inode 2. From , or if you have Sun's NFS in your kernel: * The root inode is the root of the file system. * Inode 0 can't be used for normal purposes and * historically bad blocks were linked to inode 1, * thus the root inode is 2. > root) of block device b and says any access to (B,I) is really an > access to (b,1) and an attempt to access .. from (b,1) is really a > access of .. from (B,I). > A generalised mount would link (B,I) to (b,i) and say that access > to (B,I) yields (b,i) and an access of (b,i) yields (B,I), with > appropriate handling of . and .. (yes, .. IS something special). > This way we can effectively swap any two subtrees of any two file > systems [which is a Good Thing]. > This overcomes the /usr/include/sys problem, No, because then the include files disappear from /sys/h! > cleans up the mount command, Symmetric mounts make networked filesystems nearly useless. Imagine: machine foo has something, say /usr/man, that machine bar wants to access. So machine bar mounts: % mount foo:/usr/man /usr/man Now all of a sudden foo has lost its own /usr/man because it got replaced with bar's /usr/man, which is empty - after all, that's why bar wants to import foo:/usr/man. der Mouse (mouse@mcgill-vision.uucp)