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: <3728@elecvax.eecs.unsw.oz>
Date: Sun, 6-Sep-87 18:56:48 EDT
Article-I.D.: elecvax.3728
Posted: Sun Sep  6 18:56:48 1987
Date-Received: Tue, 8-Sep-87 02:55:02 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2912@ulysses.homer.nj.att.com> <1811@munnari.oz>
Organization: EE and CS, Uni of NSW, Sydney, Australia
Lines: 78

>From: kre@munnari.oz (Robert Elz)
>Date: 3 Sep 87 16:26:44 GMT

>Finally, others suggested generalized mount as a solution to this
>problem.  I have no objection to that concept at all, however it
>doesn't really solve the problem.
>
>First, symlinks are user definable things, mount is generally
>an administrators tool.  As a user I want to be able to make
>pointers to directories, and I don't want to lose that ability.
>
>Second, unless the semantics of mount are changed more than I think
>was intended when this is done, when you "mount" /sys/h on /usr/include/sys
>you are effectively removing /sys/h from its old position, and putting
>it under /usr/include.  Whether than means that references to /sys/h
>now fail, I don't know.  If they do, then that is not the object at all.
>If they don't, then "/sys/h/.." would be "/usr/include" which doesn't
>seem to be the object either.

Indeed, /sys/h would become the stub directory that /usr/include/sys was
before the mount. But is that really so bad?
I recall when I first saw a
	#ifdef KERNEL
	#include <../h/thing.h>
	#else
	#include <sys/thing.h>
	#endif
I thought this was somewhat repulsive. Why can't the includes always be
in the same place.  If we want to different include files we convince our
makefiles to give a -I flag to cpp - probably via the environment.

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.

There are two sub-cases for this question:
1/ Public directories,
2/ Private directories.

For public directories I say NO, No a thousand times NO.  In a well ordered
system there should be a place for everything, and everything in its place.
Only the insecure need two homes.

For private directories the situation could be different. I have occasionally
played with symlinks, but not found a lot of good uses - but maybe I'm
just unimaginative.

So, I ask - an open question. What uses do you have for symbolic links to
directories?
 - If you are just moving things from one file system to another, it is a
   generalised mount you want. (I don't think many ordinary users will have
   this problem - will they??)
 - Is it just an alias, a keystroke saver. If so, it is my feeling that the
   shell is the place for aliases. If they are just aliases, would you really
   want to put them in a program. If not, the shell is the `right' place.
 - Is it a convenience that could be better (or at least satisfactorily)
   handled by one of the many Paths (PATH, CDPATH, -I for cpp includes,
   -L (i think) of ld libraries, MANPATH ...).
 - Or do you REALLY want the file system to think that the directory is in
   two places at once. If so I would be interested to know of the use.
   ( I may be able to use it to my advantage some day...)

In answer to kre's use for symlinks in WonderDatabaseApplication
(a use which clearly shows holes in Krell's solution) I would suggest
the time honoured configuration solution of a
.WonderDatabaseApplicationRC file containing the directory names.
It works for other programs, why not this one?

A final note, I'm not really suggesting that symlinks to directories should
be banned in private (I abhor them in public). They can be very useful for
the occasional quick-and-dirty.
But do you really want them on such a long term basis that programs may
use them and want to be able to `..' out of them?

All answers welcome, by news or mail as you see appropriate.

NeilBrown