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)