Greg A. Woods writes:

>Indeed it would be dangerous to imply that a userland implementation of
>funlink() could do something that, as a userland implementation, it most
>certainly could not possibly do.
>
>As we've explored funlink() doesn't make sense as solution for unix-like
>systems for very different and far more practical reasons, and it is the
>explanation of those reasons that leads to learning what must be done
>instead and how the alternatives could be optimized.

IMHO, the best solution (albeit outside the established Unix framework)
would be to fully separate operations on directories and the flat file
system (inodes/device-numbers or equivalents)...  There would be an
operation, let's call it lookup() : pathname -> identifier, to
translate a symbolic pathname into a more or less opaque identifier
(similar to an fd) which is unique and reversible for both the
referenced file and the directory entry during the period of its
allocation to the process.  Open(2) would then take this identifier to
actually open the file, not a pathname.  The advantage would be that
the application would have a handle on the actual directory entry,
other than the volatile pathname.  One could then use something like
funlink() on that identifier to delete the directory entry and simulate
unlink() without having to care for the case that a new entry with the
same name has been established in the directory in the meantime.
Unfortunately this poses several problems: some filesystems cannot
easily produce such an indirection, it has to be emulated on them
(should be feasible, though), and it doesn't work with the current
established Unix filesystem API.  It somewhat surprises me in hindsight
that such an approach was not taken in the original Unix
implementation.  However, I guess, this is influenced by the fact that
most likely the open()-style API was established already before Unix
got real directories (and perhaps also to keep it stupid simple.)

-- 
  Matthias Buelow;  mkb@{mukappabeta.de,informatik.uni-wuerzburg.de}