Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!linus!philabs!micomvax!musocs!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.unix.wizards Subject: Re: symlinks, and potential variants thereof Message-ID: <845@mcgill-vision.UUCP> Date: Tue, 21-Jul-87 02:49:28 EDT Article-I.D.: mcgill-v.845 Posted: Tue Jul 21 02:49:28 1987 Date-Received: Mon, 27-Jul-87 00:35:40 EDT References: <2629@ulysses.homer.nj.att.com> <390@murphy.UUCP> <898@rtech.UUCP> <241@nuchat.UUCP> Organization: McGill University, Montreal Lines: 40 In article <241@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: > (Isn't is about time we changed the subject line? :-) Yes. So I did. > 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 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 ...". I have often come up against the problem of a directory containing a bunch of symlinks to files in another directory, just as you described. The usual case is a source directory on our Suns, where I want all or most of the source files (.c and .h) to be symlinks to a parallel directory on our VAX, but the .o and executables to be local. What I was considering doing about it, though, was to implement a "generic" symlink. This would be an object which could contain files just as a directory does, but when a lookup is done, if the name being looked for is not in the generic-symlink directory, the kernel follows the symlink and looks there. This is a pipe dream at the moment. In particular, I see problems with opening a file for write (assuming it doesn't exist in the generic-symlink directory). Should it follow the link or not? In the usage I mentioned above, it depends: for a source file, it should follow the link; for a .o file, it should create it locally. Perhaps it should depend on whether it's been opened for reading previously. Perhaps the semantics are wrong: perhaps opening a file for read and finding it in the symlinked-to directory should create a local symlink for later use. Perhaps lots of things. Any ideas? der Mouse (mouse@mcgill-vision.uucp)