>>the point is that the file, while backed by disk space somewhere, does
>>not really exist, and gets deallocated when the file descriptor is
>>closed.  it's sort of like kernel support for tmpfile, but safer.
>
>I'd suggest that if this is implemented, one would consider it a
>logical analogue to mmap(2)ing anonymous pages, i.e. it would be
>simply swap backed.  Of course in order to make it properly useful
>one would want to have an flink(2) syscall, so that one could put
>it somewhere.  ;-)

sort of an analogue, but different because instead of having an
arbitrary pointer to some piece of data, you have a file descriptor.
i think that doing it using the normal file system backing it would be
easier.

as for flink(2), no.  flink(2) would be a terribly bad idea.  consider
that when opening a file, *all* the permissions on *all* the inodes in
the path to the file are considered.  if you were able to get some
process to hand you an open file descriptor to some file somewhere
that relies on being protected by permissions in the path and you were
able to flink(2) it to some arbitrary name, you could bypass the
permissions set that had been established.

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