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

quoted text
>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