>>...
>> 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().

but i still have to worry about racing someone to opening a file with
a random name that i only want for a short time.  i was thinking of
something like tmpfile(), but different in that (a) it returned a file
descriptor and not a FILE*, and (b) the name never gets created so
there's no need to follow it immediately by a call to unlink().

this is just another of my silly ideas.  :)

>> 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.

interesting idea...

but after a good night's sleep, a dream told me that compat_fs would
be just fine mounted on a directory somewhere, with symlinks forming
the necessary glue between where the files are (in the compat_fs file
system) and where they needed to be (in /var/run or /var/log).

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."