Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!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: <7955@brl-adm.ARPA> Date: Mon, 22-Jun-87 20:58:34 EDT Article-I.D.: brl-adm.7955 Posted: Mon Jun 22 20:58:34 1987 Date-Received: Tue, 23-Jun-87 07:25:30 EDT Sender: news@brl-adm.ARPA Lines: 64 Well, I seem to have found myself a subject I can sink my teeth into! In article <2211@bunker.UUCP>, zink@bunker.UUCP (David Zink) writes: > What's wrong about more than eight symbolic loops? Good explanation [deleted]. 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). Unfortunately, too many people seem to agree with you. 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. Another good point. Let us be wizards. 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 Yes. I guess the originators figured that the target files modes would do the real duty. But if so, why make ch{own,grp} affect the link? bits, and I'm sure a meaning for sticky will come to me! I would like For the TPC folks, the sticky bit would let subsequent `..' mean `back' rather than up. 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, Careful, you might break code! 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. One thing I *would* like to see is to make `ls -F' report symlinks that resolved to directorys marked with a trailing *back*slash, rather than just a slash. That way we could tell the difference. kre (Root Boy) Jim Cottrell National Bureau of Standards Flamer's Hotline: (301) 975-5688