Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!terra!brent
From: brent%terra@Sun.COM (Brent Callaghan)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic links and RFS
Message-ID: <106760@sun.Eng.Sun.COM>
Date: 25 May 89 19:46:05 GMT
References: <563@Aragorn.dde.uucp> <1662@auspex.auspex.com> <10300@smoke.BRL.MIL> <31533@bu-cs.BU.EDU>
Sender: news@sun.Eng.Sun.COM
Lines: 34

In article <31533@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
> 
> 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.
> -- 
> 	-Barry Shein, Software Tool & Die

Well this almost how the automounter in SunOs works.  It mounts
itself in the filesystem on the host and pretends to be a directory
NFS mounted from another server.  It responds to the NFS RPC calls
from the kernel and sends back appropriate responses.  This
interposition allows the automounter to catch references to
filesystems and mount them on the fly.

The latest version of the automounter can also emulate a symbolic
link at its mount point.  It can point the symlink wherever it
pleases when the kernel does an NFS READLINK request. Things can
get a bit slippery when it comes time to unmount this thing - but
that's a whole 'nuther story....

Although I know of no examples, there's no reason why such an
NFS daemon couldn`t emulate a regular file at its mount point 
and behave accordingly when the kernel issues READ and/or WRITE
requests.

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 1051