On Mon, 24 Sep 2001, Andrew Brown wrote:

> <wandering type="random">
>
> before i started toying with the portal stuff, i imagined that i'd do
> this:
>
> 	netbsd/	rfilter	netbsd/	/root/cvs.pl netbsd %s
>
> and then supply a script (/root/cvs.pl) that would suck the desired
> stuff out of cvs, stuff it in a file (in, eg, /tmp), and pass back an
> open fd to it.  nope.  not quite.  (it'd also be nice if there was a
> way to ask open(2) for a file descriptor open on a file on the disk
> that had no hard links to it so that space would get deallocated on
> close...)

True, but since you have to give open a path, you can follow it with a
call to unlink().

> portal can't do that, so clearly that won't suffice for backwards
> compatibility to a file like wtmp (or utmp).  reads would work, as
> would seeks, but writes would be worthless.  the other problem with
> writes is that utmp and wtmp are record based, but there's currently
> no enforced restriction on that.
>
> this strikes somewhat, at this point, as the difference between the
> block and character interfaces to, eg, disk drives.  which, i guess,
> makes it look something like the "sharity light hack" that someone
> already mentioned.  the only "problem" is that files aren't currently
> mount points.  i guess one could union mount a compat portal daemon
> over (under?) /var/log and /var/run...

Yeah. AIX for instance would let a file be a mount point.

Take care,

Bill