Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rochester!cornell!uw-beaver!mit-eddie!ll-xn!ames!lll-lcc!ptsfa!hoptoad!academ!uhnix1!nuchat!steve From: steve@nuchat.UUCP (Steve Nuchia) Newsgroups: comp.unix.wizards Subject: Re: symbolic links are a botch Message-ID: <241@nuchat.UUCP> Date: Tue, 23-Jun-87 01:49:45 EDT Article-I.D.: nuchat.241 Posted: Tue Jun 23 01:49:45 1987 Date-Received: Sun, 12-Jul-87 10:52:09 EDT References: <2629@ulysses.homer.nj.att.com> <390@murphy.UUCP> <898@rtech.UUCP> <8738@tekecs.TEK.COM> Organization: Public Access - Houston, Tx Lines: 79 Summary: My "link-to-directory" fantasy feature (Isn't is about time we changed the subject line? :-) In my experince, which is oriented towards software engineering in general and portable commerical software in particular, links to directories are about a 70% solution - they are helpful but aren't _exactly_ the right thing. Let me describe what I've whished for, and show how it could be useful in other contexts. Instead of allowing directories to be links to another directory, have an object with the superficial semantics of a directory but implementing a "copy-on-write" window onto a search path of other directories, perhaps chained to arbitrary depth. I'm not concerned with implementation directly here; please allow me to speak (?) a little metaphorically. As a version control mechanism the application is obvious: each version is a "copy-on-write" image directory, with files carried through from previous versions visible but not modifiable. A similar scheme was described in the Portland usenix proceedings under the title "A Rich Man's SCCS" or something like that. The author modified a large number of standard utilites, notably cp and the editor, to achieve essentially the semantics I describe using standard hard links. In environments requiring customized bin direcories, notably heterogenous NFS nets and "universe" implementations, the standard practice is to have a directory for each requirement, with each NFS host symlinking or mounting or whatever the right one. In universe implementations it is customary to have the symlink mechanism switch off of the universe flag. The shortcoming in both cases is that files held in common between the two require special maintenance (shell scripts? ...). My directories would simply have the shared stuff in the right place and then different folks would search for their different strokes by following their appropriate links. (A similar requirement was brought up not too long ago in reference to the netnews software: In a NFS environment the "libdir" need sto be "purified" of binary files; a perfect application of this concept). I have occasionally had to build a directory with a link to each file in another directory and then make a few small changes in the set of files: a deletion here and an addition there. Situations come up often where it would be nice to be able to set up a directory "just like" another "except for ...". Sure, there are (almost) always workarounds, but you recognize what I'm talking about, don't you? Then there's rsh bin directories (Restricted, not Remote SHell), various reasons for a writable copy of a read-only directory, etc. In fact, wouldn't it be nice if ~/bin was an image-link to /bin:/usr/bin? Sure, we've got mechanisms for doing the same thing, but it would be a cleaner world without execvp(2). :-) Implementation shouldn't be a huge challenge, and I'd use this a lot more frequently than links to directories. If I wanted the other directory I'd just use it: Except for crossing mount points, symlinks to directories are of precious little use to me. Image links are a horse of a different color, And I'd like to hear from those in whom my remarks strike a responsive chord. The semantics of the proposed facility need to be nailed down, and an existance proof of implementability need to be sketched. (needless to say, the implementation scheme will define the semantics as usual, but we can dream, right? :-)). Flames to /dev/null: I've thought about this a lot and would like the courtesy of a well thought out refutation. 1/2*:-) It is my hope that this will serve as a fulcrum to turn the discussion away from all the things that _are_ wrong with links to direcories and towards a better way to do their job. I could probably do a better job on the presentation if I didn't try to write this late at night, but its now or never... Thank you for your attention. Steve Nuchia (713) 334 6720 voice {housun,{soma,academ}!uhnix1}!nuchat!steve (713) 334 1204 2400N81 "trouble" sends anonymous mail to me.