Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!cmcl2!rutgers!bellcore!faline!ulysses!hector!ekrell
From: ekrell@hector..UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <2854@ulysses.homer.nj.att.com>
Date: Mon, 24-Aug-87 21:02:19 EDT
Article-I.D.: ulysses.2854
Posted: Mon Aug 24 21:02:19 1987
Date-Received: Tue, 25-Aug-87 07:19:06 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2838@ulysses.homer.nj.att.com> <1793@munnari.oz>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: ekrell@hector (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 55

This is really getting annoying ...

In article <1793@munnari.oz> kre@munnari.UUCP writes:

>> When I do a "cd /a/b" and end up in a different directory, say, /c/d,
>> then the symbolic link IS equivalent to the directory it points to.
>> Once I "cd" to that directory, I get to the same i-node as /c/d.
>> That qualifies as being equivalent, I would say.
>
>If they're equivalent, then "cd .." after either should have the
>same effect, otherwise they can't possibly be equivalent, surely?

Only if you see ".." as a physical, hard-coded pointer.

>If we're there in /c/d (a path without symlinks, as obtained from /bin/pwd)
>and you do a "cd ..", where should we go?  I say wherever ".." points,
>usually "/c", in all cases.  Simple, and consistent.  It does require
>some education about the properties of symlinks.

This argument, that ".." is a physical link (rather than a logical one)
falls appart at mount points, where the parent directory and where ".." points
are different. It also happens at remote file system mount points, for
the same reason. So it's not so "simple and consistent". It now requires
some education about file systems, mount points, and distributed file
systems. The list seems to keep growing.

>And none of this overcomes the problems with actually implementing it
>and making it work properly, assuming that you can actually produce
>a nice clean definition of what you're trying to implement.

This is easy. The intention is to make ".." behave as a logical operator.
This means that

1: if I do "cd /usr/include/sys" and then "cd ..", I end up in /usr/include
   no matter what.

2: if I find a ".." in a pathname, it refers to the logical parent,
   not the physical one. Thus, while in /usr/include/sys, "ls .." will produce
   a directory listing of /usr/include.

The semantics are very clean and simple.

>However, this all started with a proposal to move
>these semantics into the kernel, forcing them on everyone, assuming
>that an implementation is possible.  That would be a disaster.

You can't achieve 2: above unless it's done in the kernel.

An implementation is not only possible, it already exists. I wouldn't be
defending this if I didn't have the opportunity to use it and test it and
get the feeling as to whether it's the right thing to do or not.
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

    {ihnp4,seismo,ucbvax}!ulysses!ekrell