mouse@mcgill-vision.UUCP (der Mouse) (07/21/87)
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)
steve@nuchat.UUCP (Steve Nuchia) (07/30/87)
In article <845@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes: > [...] 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. > [...] for later use. Perhaps lots of things. Any ideas? Well, the thought that leapt into my mind on reading this was "why not use a program as the generic-symlink object". It would act as a filter for nami; this gets into the lightweight process thread and probably a few others. But this is exactly the idea I'm working on in my research, ie an "object oriented" operating system, and as has been pointed out already it would be stretching things to call such a system "UNIX". But we are all entitled to our pipe dreams, aren't we? Steve Nuchia 334 1204 (hire me) {housun,{soma,academ}!uhnix1}!nuchat!steve