In article <20030714163427.GA17303@moghedien.mukappabeta.net> you write:
>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.

NetBSD actually has a mechanism that works like this.  Look at getfh(2) and
fhopen(2).  It's designed for implementing NFS servers, so there's no
security and hence they can only be called by root, though.

>The advantage would be that
>the application would have a handle on the actual directory entry,

You suggested that the flat file-system would use i-nodes, not directory
entries.  The distinction is important (and file handles refer to i-nodes,
so they wouldn't actually be useful for funlink()).

-- 
Ben Harris