Subject: Re: funlink() for fun!
To: None <email@example.com>
From: Ben Harris <firstname.lastname@example.org>
Date: 07/14/2003 19:06:15
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()).