Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!munnari!kre
From: kre@munnari.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: symbolic links are a botch
Message-ID: <1715@munnari.oz>
Date: Sat, 20-Jun-87 14:45:11 EDT
Article-I.D.: munnari.1715
Posted: Sat Jun 20 14:45:11 1987
Date-Received: Sun, 21-Jun-87 06:59:26 EDT
References: <7879@brl-adm.ARPA> <2211@bunker.UUCP>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 80
Keywords: HUH?

In article <2211@bunker.UUCP>, zink@bunker.UUCP (David Zink) writes:
> What's wrong about more than eight symbolic loops?

There's nothing magis about 8, pick any number you like, (it should
probably be a config parameter), however there has to be a limit.

> Isn't the maximum pathname length a firm enough limit on looping?

No, symbolic links aren't expanded into the pathname, to make a long
string that is then looked up normally.

Rather, the contents of the symlink simply replace the component that
is the name of the symlink.

So, consider

	ln -s a a

then open("a", 0);

if there was no limit, the kernel would iterate on the symlink
forever, as the name length is continually 1, after every time
he symlink replaces the component.

Of course, the kernel could trivially catch this degenerate case,
but expecting it to catch

	ln -s a z
	ln -s b a
	ln -s c b
	...
	ln -s z y

is expecting a little too much.

On the general question of symbolic links .. I have changed my
opinion on them recently, not their usefulness, but on how they
should be seen to the user.  I used to believe that a symlink
should appear as a link in as many ways possible (so much that
I have always changed the sense of the 'L' flag in "ls" so that
the default is to show the file linked to, rather that the symlink
itself).

However, I'm not of the opinion that this is wrong.  Symlinks
should be regarded as real objects, and not as poor cousins.
I'm no longer going to fool with "ls".

Most of the "problems" with symlinks seem to be because we seem
to want to forget that symlinks exists, and just pretend that they
are directories (to the extent of having ".." reverse a symlink,
a totally absurd idea).

Much better would be to simply educate users, let them see symlinks
as real objects in the filesystem.  At the minute, I have to know
that 'foo' is a directory before I attempt "cd foo", I'm expected
to remember that (or discover it).  Expecting users to know that
'foo' can be either a directory or a symlink, and that which it
is causes different effects, isn't too much to ask I think.

Its time for symlinks to come out of the closet.  Stand up and be counted!

This does mean implementing sensible semantics for most of the sys
calls when applied to symlinks, chmod should work (rather than passing
through), and the modes should mean things.  "r" would let you see
the contents of the symlink, "w" allow you to change it, and "x" to
access its value in a path lookup.  I have ideas for the set[ug]id
bits, and I'm sure a meaning for sticky will come to me!  I would like
to discard "readlink" and replace it with "read", probably with an
extra mode to open to say "don't follow".  Then "write" could be used
to change the value of a symlink ("symlink" could be replaced by
"mknod, write" but I think that's going a bit far).  Rename, unlink,
and chown already work properly.  stat and lstat are OK.  Access is
a tricky one, an extra "don't follow" mode bit is probably needed there.
"Link" is hard, both meanings make sense, and there's no flags word
with convenient unused bits in it.  This might necessitate a new syscall
(ala stat/lstat which was in the same position).  The sys calls that take
a path for some odd purpose (acct, mount, etc) should just operate as they
do now.

kre