Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic links and RFS
Message-ID: <31533@bu-cs.BU.EDU>
Date: 21 May 89 16:46:32 GMT
References: <563@Aragorn.dde.uucp> <1662@auspex.auspex.com> <10300@smoke.BRL.MIL>
Organization: Boston U. Comp. Sci.
Lines: 36
In-reply-to: gwyn@smoke.BRL.MIL's message of 21 May 89 03:05:03 GMT


From: gwyn@smoke.BRL.MIL (Doug Gwyn)
>You don't have to be using a network file system to have symbolic
>links point at different files depending on context.  Even on
>traditional UNIX, changing the mount configuration can affect the
>target of a symbolic link.  As I've said before, I think symbolic
>links were an unsuccessful experiment; a better solution is needed.

I think that's harsh but the question deserves discussion.

Symlinks generalized hard links by delaying the evaluation of the file
path until access time (although the effect seems more dramatic this
is basically what the difference is.)

The next obvious extension would be to delay the creation of the file
path string until access time.

The easiest way to do this would be to have a file type which is
actually a program which promises to produce a string for namei.

Accessing the inode fires up the program and waits for the resultant
string which specifies the rest of the path to use.

Just as a pre-emptive comment I think immediately going after all the
ways this might be abused is not yet interesting since safeguards
could be added and obviously the design is not yet fleshed out enough
to take seriously someone pointing up bugs. Its utility and possible
implementation details would be interesting (it might not make it past
that scrutiny so why bother nitpicking possible bugs is my point.)


-- 
	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.