[ On Thursday, July 10, 2003 at 23:41:40 (-0400), der Mouse wrote: ]
> Subject: Re: funlink() for fun!
>
> Neither is of any real use by itself.
> 
> 	fd = open("/home/alice/fnord/flarp",O_WRONLY|O_CREAT|O_EXCL,0666);
> 	chdir("/home/carol");
> 	rename("../alice","/home/bob");
> 	funlink(fd); /* What does this do?  Why and how? */

If you don't have an opened filename cache then assuming the rename()
works (i.e. assuming /home/bob isn't a mount point) then the funlink()
call would unlink that newly created file no matter what its name (which
does suggest one possible reason which might make funlink() useful even
if the application does know the original name of the file).

> Even if you cache the pathname passed to open, even though the rename()
> does not have anything obvious to do with the open()ed path, even
> though file still has only one hard link, you have to search the
> filesystem.

If you do have an record of the opened filename then I would say the
easy way out means the funlink() must simply fail because it would be
exactly equivalent to:

	unlink("/home/alice/fnord/flarp");

(I should clarify that what I have been implying by the "opened
filename" is a fully qualified name which would have to be computed
using sys/kern/vfs_getcwd.c:getcwd_common() or similar if the name
passed to open was a relative one.  Caching the process' cwd vnode at
the time of open for each open file (even if only for those opened with
relative names) would probably complicate far too many other things to
be worth considering.)

I guess the choice between just failing the funlink() call in your
example above, or trying to make it work if possible, depends on what
possible reason one might have for implementing funlink() in the first
place, and thus how one defines it.

If all one is trying to do is flesh out the set of f*() system calls
which have file descriptor parameters to make it orthogonal to the set
which have pathname parameters then I suppose it depends on who one
wants to pay the price for this feature (and perhaps whether or not one
can conceive of any other reason to bother caching the opened filenames.
(Note this fleshing out of the f*() system call set was the original
purpose I had when I played this same mental exercise many years ago.)

If on the other hand what the funlink() implementor is trying to do is
actually make the funlink() call "work" no matter what name the opened
file might have at the time of the funlink() call is made then, as you
say above, caching the opened filename may not be any help and one
really does have to force the caller to pay the price of the directory
search.  Caching the opened filename could help allow the call to
succeed even when the link count is greater than one, IFF the original
file still has the same pathname, of course.

(I suspect always caching the file's parent directory vnode for all open
files as well would also add too many more complications, and it still
wouldn't help if the rename changed the file's parent directory.)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>