Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <4477@ncoast.UUCP>
Date: Sun, 6-Sep-87 21:32:13 EDT
Article-I.D.: ncoast.4477
Posted: Sun Sep  6 21:32:13 1987
Date-Received: Tue, 8-Sep-87 01:19:39 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2912@ulysses.homer.nj.att.com> <1811@munnari.oz>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 76

Perhaps the time has come to consider alternatives to symbolic links.  The
alternative should coexist with both standard filesystem semantics and
symbolic links.

Some possibilities are:

(1) Generic links.  These would be special files containing, not pathnames,
    but (device, inode) pairs.  These could also be generalized into
    directory unions by storing multiple (device, inode) pairs, possibly
    along with an attribute word specifying whether to allow file creation,
    etc. in that member of the union.  While this looks like a nice thing
    to have in general, it doesn't solve the problem.

(2) Multiple backpointers.  This isn't much different from storing the
    entire path (or device/inode numbers for same), unfortunately; no
    solution.

(3) Accept the fact that you can't do it rationally; the whole reason
    multiple links to directories are discouraged in the first place.
    This implies that symbolic links to directories are persona non grata.
    Somehow, I doubt that this is an acceptable solution, even though it
    solves a number of potential problems.  (I'm minded of a fool on an
    Altos which had an important database directory symlinked over the
    Worknet; this jerk saw that the link count was 1 for large files on
    both machines, concluded that there were duplicate files, and deleted
    them on "one" machine; this, of course, blew them away for good.  This
    same fool hadn't been doing backups, of course... and did even more
    stupid things when I tried to recover them.  Another story for later.)

(4) Force a user to be explicit in forward/backward pointer following.
    I'll use the ">" and "<" from Multics, in an unorthodox way, to show
    the forward and backward pointers; for UNIX, we'd have to invent
    a backpointer separator, since using ">" and "<" not only overloads
    them from the shell but also forces people to learn to use ">" in
    place of "/".  Alas, we can't steal "\" for this unless we change
    the escape character, which is even hairier....
    
    $ mkdir a b a>c
    $ ln a>c b>c
    $ cd a>c
    $ pwd
    /u>allbery>a>c
    $ cd <b>c
    $ pwd
    /u>allbery>b>c
    $ cd <
    $ pwd
    /u>allbery>b
    $ cd c
    $ cd <a
    $ pwd
    /u>allbery>a
    $ _

    Not only is it ugly, but it places a burden on the user which we're
    trying to avoid anyway; we may as well throw out symlinks entirely,
    it's just as much of a burden (in fact, less) to use full pathnames
    than to do this.  Moreover, the meaning of unspecified "<" is still
    not well defined unless you save the pathyou used to get there in
    the first place.

Maybe someone out there can come up with a better way to do it, but I doubt
it; the whole purpose of the tree structure is to make it unnecessary to
carry the full pathname around in order to get from point A to point B
when point A is a "parent" of point B.  I, myself, vote for disallowing
symlinks to directories; it's the long way around for /usr/include/sys ->
/sys/h, but it's also not ambiguous.  Either that or carry the path around,
either as a string or as (device, inode) pairs; and this places a limit
on the length of a path, which is an unreasonable restriction.
-- 
	    Brandon S. Allbery, moderator of comp.sources.misc
  {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery
ARPA: necntc!ncoast!allbery@harvard.harvard.edu  Fido: 157/502  MCI: BALLBERY
   <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>
All opinions in this message are random characters produced when my cat jumped
(-:		      up onto the keyboard of my PC.			   :-)