Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!hao!husc6!cmcl2!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: symbolic links are a botch Message-ID: <7879@brl-adm.ARPA> Date: Tue, 16-Jun-87 17:02:32 EDT Article-I.D.: brl-adm.7879 Posted: Tue Jun 16 17:02:32 1987 Date-Received: Sun, 21-Jun-87 07:53:28 EDT Sender: news@brl-adm.ARPA Lines: 113 In article <7724@brl-adm.ARPA> rbj@icst-cmr.arpa writes: >I think the key word here is "the". The kernel implements symbolic >links as you describe below; the csh maintains $cwd symbolicly. If you >do `cd /foo/bar' where /foo/bar -> /whiz/bang followed by `cd ..', >$cwd gives /foo while pwd gives /whiz. Thus csh is interpreting `..' >to mean `back' while the kernel takes it to mean `up'. So the question is: where should you end up?. Ignore for a moment the problem of where this special treatment of ".." belongs (shell, kernel, etc). The question is: if a user does a "cd /foo/bar" and then "cd ..", is it reasonable to expect to be in /foo whether /foo/bar is a symbolic link or not?. Yes, it is reasonable. Is it the best thing to do? Maybe. If you write a shell that does this, I won't barf. It would be nice if the behavior was controlled by a switch (some have done this). One could even use the notation `...' to mean "*rindex(cwd,'/') = 0;". Strrchr for TPC folks. >In fact, symbolic links are no worse than when root makes links >between directories. The possibility exists for loops The kernel will detect a loop with symbolic links when the count of symbolic links being encountered by namei() while translating a filename exceeds some constant (8, I think). I know that, and it's irrelevant. But it won't detect hard link loops, except by length of pathname limits. One of my points was this: cd /usr; mkdir a; mkdir b; ln -s /usr/a b/a; ln -s /usr/b a/b cd a; cd b; cd a cd ..; cd ..; cd .. In a case like this, the shell would have no problem, but the kernel would have to remember the entire history of how you got here. After line 3 csh would think we were in /usr/a/b/a, which is really /usr/a. The first exit out of a takes us to /usr/b, but the second takes us to /usr. > What would be the best semantics for ..? > >Exactly what they are now as far as the kernel is concerned. The kernel has no history of pathnames. Your working directory is inode 347. In fact, maybe it should. Allow me to restate Korn's proposition as "THE IDEA OF A DISEMBODIED `WORKING DIRECTORY' IS A BOTCH" Why not just go all the way? Keep *both* pieces of info in the inode in core: where we are (inode 347), and how we got here. Keep the same semantics for `..' since our graphs will still look pretty much like trees, and make `...' be `where you came from'. Obviously, ... cannot be kept on disk, and the kernel would have to implement the semantics of `...'. Right now, it doesn't know about `.' and `..'. Symbolic links would *not* be resolved in the inode structure. The problem ("cd /foo/bar; cd ..") still remains, then. You could argue that the special treatment for ".." belongs in the shell, but then what about a program that does a chdir or the C preprocessor searching for "../x.h" ? We would really have to change all the programs that deal with filenames and put special code in them to deal with "..". This is clearly wrong. One should be careful when using links, hard or soft. I would add, however, that bombing out when `../x.h' cannot be found is better than finding another x.h in another directory. "Hey Ralph, I can't compile this!" "Yeah? Did you cd thru a symbolic link to the source directory?" "Yeah, I've been cd'ing all over the place. I better login again." This is clearly even worse. Use `#include ".../x.h"'. On second thought, DON'T! Or the anecdote I described becomes a nightmare! >what happens when you type `cd ..', I can see several alternatives. >Possibly the best is to not treat it specially. Why?. A user that does "cd /foo/bar" and then "cd .." expects to be in /foo. He/she doesn't know and DOESN'T NEED to know that /foo/bar is a symbolic link. Naive users don't even know what symbolic links are. Those last two statements contradict each other. It would be nice if one didn't have to know about symbolic links. However, if /foo/bar points to /qaz/wsx, then he needs to know! Besides, no one can remember what directory they're in anyway. That's why we have the pwd command, or have $cwd as part of our prompt. And the latter fails across symbolic links. >consider the case of loops, where after `descending' into the same >directorys a few times and realizing what happened, do you want to >retrace your steps in reverse, or go straight up as fast as possible. That is not me being quoted. I think it's Korn. The answer is, possibly either. So gimme both `..' and `...' please. Let the kernel deal with the loops. As I said before, after a number of symbolic links are encounteres, it gives up with an ELOOP error. Well, loops are pretty pathological in either case. Even without loops, the same problems exist. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell (Root Boy) Jim Cottrell National Bureau of Standards Flamer's Hotline: (301) 975-5688 Hello. Just walk along and try NOT to think about your INTESTINES being almost FORTY YARDS LONG!!