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: <2925@ulysses.homer.nj.att.com>
Date: Fri, 4-Sep-87 21:18:16 EDT
Article-I.D.: ulysses.2925
Posted: Fri Sep  4 21:18:16 1987
Date-Received: Sun, 6-Sep-87 03:24:26 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2912@ulysses.homer.nj.att.com> <1811@munnari.oz>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: ekrell@hector (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 123

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

>Its definitely time to stop this disussion, its getting nowhere

We finally agree on something...

>But they're the same place.  Isn't that the whole point of a "link"?
>Whichever name you refer to you get the same, identical, object, with
>the same properties as all other names that refer to the same object.

But the point is that it should be transparent to some degree to the user
(one of the argument is just how much transparency they ought to have).
The user shouldn't know /usr/include/sys is a symbolic link and shouldn't
care.

>If you're trying to make symbolic links hide themselves in the filesystem
>and almost appear not to be there at all, I would have thought that this
>would have been one of the fundamental properties you would have been
>determined to preserve.

I do want to hide them, much the same way one hides the implementation
details from an abstract data type (ADT). The user doesn't know how an
ADT is implemented and if he does know, he can't rely on that.

>I still want object X to be object X, regardless
>of its past history.  Can you really not imagine the confusion
>such a change would cause?

I imagine it would never be as bad as the confusion caused by the current
implementation of symbolic links. In my implementation, "cd /usr/include/sys;
cd .." always puts you in /usr/include.
An implementation that doesn't do that is confusing.

>Given that, do you really want to be immortalized as the AT&T
>person who forced your semantics of symlinks into a public
>release, only to have it changed in the next release because
>of the outcry?

No, I want to be immortalized as a person who helped to restore
the tree structure to the Unix File System and who implemented
symbolic links in a better, consistent way.

>Would you like to be whoever it was that suggested that Sys V.0's
>compiler (or linker, or whatever) should require "extern" on all but
>one instance of an extern variable, even though just about everyone
>would agree that that change was "right"?

I don't know who is "just about everyone" in this case. It certainly
wasn't my idea or Dave Korn's idea or anyone else in Bell Lab's research
area.

> Ed Gould provided a counter example
>that you seemed to just shrug off without really understanding it.

I fully understood it. What you don't seem to understand is that his
program generated filenames that were unusable since they couldn't be
referenced from outside because of the limit of 8 symbolic links in
a pathname.

I hoped my argument was clear enough, but I will be happy to provide
a more detailed explanation if anyone still doesn't understand it.

>First, let us agree that one of the properties of unix systems that
>we do want to preserve, is that there isn't any system imposed limit
>on how long a process can execute normally, if it can execute its
>major code loop few a few thousand iterations, it should be able to
>just keep on doing that forever.
>
>There are all kinds of other limitations on processes (number of open
>files, amount of memory, ...) but none that affect continuous execution.

Well, a program that tries to open a zillion files (and who checks the
returned values from open()) will "fail" when it reaches that limit.
A program that calls malloc() forever will "fail" sooner or later.
I don't quite understand your definition of "continous execution".

>Now the application looks something like this
>
>	for (;;) {
>
>		chdir("a");
>		process_a_data();
>		chdir("b");
>		process_b_data();
>
>	}
>
>with no other chdir sys calls anywhere.

There should be a chdir("..") after calling process_a_data() to put you
back in the original directory, right?. (of course, if "a" is a symbolic
link and you're still using the BSD semantics, then you can't get back
to the original directory with chdir("..") ... your example illustrates
the broken semantics of symbolic links).

>But after those years, my customer decides that he can afford a big new
>disc, and on this he's going to be able to put all the files into
>one tree.  Lets call the new place /disc3.
>
>First he moves all the data files, then
>
>	chdir /disc3
>	ln -s . a
>	ln -s . b
>
>and he starts the application running.  How long does your implementation
>give it before things start mysteriously failing?

I can't really see why my implementation would break. Can you please explain
me how you THINK my implementation works and why do you think it will break?

>Please actually try this code on your implementation

before I do that I need a good main(). Do I or don't I need the chdir("..") ?

>If your implementation uses the "store the path" technique

Tell me what is the "store the path" technique and I'll tell you whether
we use it or not.
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

    {ihnp4,seismo,ucbvax}!ulysses!ekrell