Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!moncskermit!basser!elecvax!neilb
From: neilb@elecvax.eecs.unsw.oz (Neil F. Brown)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic links
Message-ID: <3711@elecvax.eecs.unsw.oz>
Date: Mon, 31-Aug-87 06:02:20 EDT
Article-I.D.: elecvax.3711
Posted: Mon Aug 31 06:02:20 1987
Date-Received: Sat, 5-Sep-87 01:57:06 EDT
Organization: EE and CS, Uni of NSW, Sydney, Australia
Lines: 107

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.
I realise this has already been thought of, but I feel it was
discarded too quickly.

Firstly I would like to point out that it is entirely possible to
disallow such links. We simply have namei() fail if the target of
a symbolic link is a directory (ENAUGHTYSYMLINK) - possibly using
the sticky bit to turn off this restriction.
However, this restriction is not really needed, just have ln complain
if the target is a directory (or if the target doesn't exist??),
tell users how silly symlinks to directories are, and dont put
them in public places. i.e. give people enough rope but tell them
not to use it.

"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.  As many non-kernel programs
   use them, they should be in a standard place. This place seems
   to be X/sys where X is known to /lib/cpp and is probably
   /usr/include.  (Further, X should be the home directory of
   user `i' so users only need use ~i.)

   If you want to test compile a new kernel, use the -Iplace option.

   "But", you argue, "we want the kernel includes to be on the same file
   system as the kernel sources, and if this is not /usr, the above
   won't work!"

   I fully agree the includes should be physically near the sources
   but I wouldn't use symlinks to put them in their logical home,
   I would, instead, fix the mount command. i.e. cure the problem,
   not the symptom. See below for modified mount.
   First, other apparent uses for symlinked directories.

2/ Subtree Y belongs logically in place /Path/ but there is insufficent
   room on that file system. So, move it to /BIGFILESYSTEM/Y and symlink
	/Path/Y -> /BIGFILESYSTEM/Y
   Again, a problem with mount, NOT another job for SymLink. See below.

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. (Notice that with upper case
   variable names, the whole interesting-place name is typed with
   the shift key down, easier on the fingers).

   So that's not a good excuse for symlinks to directories.

4/ Pseudo directory unions - linking some directories and some files from
   another project so you can make small changes without vast copying.
   This is a case when you almost do want a directory to be in two places at
   once.
   But then, this would be an environment set up by people who know what
   they are doing, and who should be able to cope with any problems.
   Anyway, directories that are linked in should only be there for programs
   to notice. If the user wants to go into the directory, its contents should
   be linked across instead. (Maybe a cd which won't pass through a symlink??)

   Of course, what is really required is true directory unions.
   [ How about symlink ... is a directory to scan if name is not found
     in current directory, with mode bits determining what sort of 
     opens won't try ... (exec,read,write,creat,trunc... completely
     new meaning on mode bits, but it might work).
     This is just a quick thought - dont hold me to it.
   ]

5/ Vast numbers of other apparent uses that are simply "wrong" or could
   better be fixed by judicious use of the right PATH or -I type
   variable, or should be done properly with a different feature
   such as generalised mounting.

The generalised mount.

   The mount function links inode I of block device B to inode 1 (the 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 thus making it possible to put large subtrees on whichever
   file system has the required space, and then put the subtree
   where it belongs in the overall file tree without any messy symlinks.

   This overcomes the /usr/include/sys problem, cleans up the mount
   command, and allows the system administrator much more flexability
   in distributing available space about the directory tree.

   This is not, of course, the whole story on a generalised mount but
   any system programmer worth their salt should be able to fill in the
   details.


NeilBrown - Uni New South Wales - Australia
"Vote for the tree - not directed graphs"