Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!spectrix!John_M From: John_M@spectrix.UUCP (John Macdonald) Newsgroups: comp.unix.wizards Subject: Re: symbolic links are a botch Message-ID: <294@spectrix.UUCP> Date: Wed, 10-Jun-87 23:49:44 EDT Article-I.D.: spectrix.294 Posted: Wed Jun 10 23:49:44 1987 Date-Received: Sat, 13-Jun-87 04:03:08 EDT References: <2629@ulysses.homer.nj.att.com> <2200015@hpisoa1.HP.COM> Reply-To: jmm@spectrix.UUCP (John Macdonald) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 70 Summary: I agree In article <2200015@hpisoa1.HP.COM> davel@hpisoa1.HP.COM (Dave Lennert) writes: 1 >One problem with making ".." an operator and retrace the symbolic link 1 >path rather than the "hard link" path is that, if you cd to a directory 1 >via a symbolic link and then proceed to compile some C source which does 1 >a #include "../foo/bar.h", then you may not find the same (or any) include 1 >file. > >Similar problems arise with tags files. > >Such a context sensitive interpretation of ".." would make it impossible >to reliably setup such things. > 2 >Symbolic links are mainly a facility to get around certain unix limitations 2 >such as: you can only mount a file system at one mount point at a time (and 2 >hence all the disk space has to be used in one file subtree). It allows 2 >programs with hardcoded pathnames to traverse (one-way) and get to files 2 >even when the sysops need to place the files elsewhere. > >I applaud what you're trying to do, though. > >-Dave Lennert HP ihnp4!hplabs!hpda!davel I started to use paragraph 1 above as the basis of this followup. In the process of writing my comments, my thoughts changed so that I strongly support paragraph 2 above instead. I was intending to say that there are times when you want ".." to be a reference to the hard parent, and times when you want a reference to the soft parent, but that for a given soft link, you usually want the same parent for ALL references relative to it. Thus if an extension to soft links was made whereby at the time of creating the soft link you also specified whether it was a soft-parent-.. or a hard-parent-.. form of soft link and then the kernel would arrange either one for you. However, I then thought that once you have set up and used both of these forms for their appropriate purposes, then it would start to seem quite reasonable to want both parents available. (e.g. you run make in a soft-linked directory - you want <#include "../h/foo.h"> to go to the hard ../h, but you want to go through the soft link to your newly written version of the library - the one that you are trying to test.) This leads to wanting more versions of soft-links: "search order is: soft link only for write, soft link first and hard link second for read" and its 5000 nearly identical brethren. The concept of the soft link is a wart on the Unix file system. It is elegant, powerful, and valuable, but a wart none the less. It contravenes the important principle that ". and .. are the only circular links". This principle is an implicit assumption of much of the software on Unix systems and of most of the users. It is often used in ported source code (#include "../h/foo.h" as mentioned above). Thus, I am lead to the conclusion that soft-links to directories should be avoided in places where .. is going to be used. It is too likely to cause problems that are hard to notice and diagnose. (I can imagine an entry in the risks forum about a system that was released after successfully passing a complete test suite, except that because of an forgotten soft link, the test suite was linked and run using the old proven production library instead of the new freshly compiled library that was supposed to be getting tested.) The only system that I have access to that provides soft links specifies that soft links to a directory may only be done by the super-user. It would appear that other people have come to the same conclusion. (I presume that this is a standard restriction on all systems with soft links. If not, then perhaps it should be.) -- --------- .signature eater food --------- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm internet:Sorry. We're in range, but we're in no domain. Disc-claimer: (noun) any hack's source directory