Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!im4u!rutgers!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <1119@bsu-cs.UUCP>
Date: Wed, 31-Dec-69 18:59:59 EDT
Article-I.D.: bsu-cs.1119
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Tue, 8-Sep-87 06:01:24 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2912@ulysses.homer.nj.att.com> <1811@munnari.oz> <3728@elecvax.eecs.unsw.oz>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 94

Some suggestions.

I.
".." should always mean the same thing, whether from the shell
prompt or in a system call.

II.
Symbolic links are attached to a place in the directory hierarchy
and (in 4.xBSD) translated by the kernel.  Environment variables 
are local to a process and interpreted by applications software.

What we need is a third entity that will (a) not be attached to a 
specific place in the directory hierarchy but (b) be known to
the kernel.

Then, instead of saying

>	#ifdef KERNEL
>	#include <../h/thing.h>
>	#else
>	#include <sys/thing.h>
>	#endif

we will simply be able to say:

     #include <$SYS/thing.h>

and have $SYS be interpreted by the filesystem.  Similarly, if I
want to move to the directory that contains thing.h, I will type

     $ cd $SYS
     $ pwd
     /usr/include/sys
     $ 

And "cd .." will always move me up to the parent directory.

There is no reason why the value of SYS could not be relative.

     $ setlink ABC /usr/include/sys
     $ setlink EFG ../jkl
     $ setlink XYZ alpha
     $ cd $ABC/$EFG/$XYZ
     $ pwd
     /usr/include/jkl/alpha
     $

ABC, EFG, and XYZ look like environment variables, but they are known
to the kernel and accessed via a hash table, not a sequential search.
The hash table itself is accessible via a special entry in the normal
environment so that, for example, a library function can look for the
environment variable LINKTABLE and get some value that will let it
access the hash table directly, so the kenrel need not be involved in
all accesses, only those that are needed in system calls.

Actually, we might not even need to involve the kernel at all.  Just
change ALL interface routines that could possible get a filename and
let them perform the translation before the parameters are sent on to
the kernel.  In effect all system calls that handle filenames are
buffered via library functions that do link name translation.

What if I want to be able to see the following?

     $ pwd
     /usr/abc
     $ cd $ABC
     $ pwd
     /usr/include/jkl
     $ back
     $ pwd
     /usr/abc

This is best done by the shell, since the command "back" will be given
to the shell but never to a system call.  The shell need only keep
track of the path traced in reaching the current directory, and go back
a step in it when it sees the "back" command.

The above are just some ideas.  Now for reality.

Pick one:

     [ ] symbolic links available around 1983, that largely work
	 and are useful, though they lead to some confusing 
	 situations because the kernel and the user may interpret
	 ".." differently; may be up to 255 characters long

     [ ] symbolic links designed carefully to lead to no confusion;
	 approved after much consideration by four layers of
	 bureacracy; not currently available, and probably won't be 
	 until 1989; will probably be limited to 14 characters

Pick just one.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi