[ On Thursday, July 10, 2003 at 14:52:16 (-0700), Greywolf wrote: ]
> Subject: Re: funlink() for fun!
>
> GAW> alternately the pathname could be cached in the kernel.  ;-)
> 
> I don't get that at all, sorry.   What good would that do for a file that
> had (N>1) links to it?  If the (st_nlink == 1) restriction is not
> enforced, funlink() would be tantamount to clri...

Just to be clear I'm thinking of funlink() as relating to unlink() in
the same way fstat() relates to stat() -- i.e. it would unlink the file
that had been opened to create the file descriptor which would be passed
to it as its only parameter.

funlink(), with pathames of open file descriptors cached in the kernel,
would be _exactly_ like unlink() and wouldn't require any other magic.
Funlink() would merely unlink the file that was opened to create the
file descriptor it was passed.

Funlink() without cached filenames would have to internally do much the
same as fstat() to find the device (and then the mount point) and the
inode number of the open file.  Then the directory tree of the target
filesystem would have to be traversed to find an entry with a matching
inode number, and then if all were OK (regular file, one link, etc.)
then the equivalent of a normal unlink() would be done on the found
filename.

About the only semi-sane use of funlink() (at least that I have ever
been able to think of over the years) could be to give a process the
ability of unlinking a file that its parent process had connected to one
of its file descriptors (e.g. stdin).  Of course such an ability would
still be pretty much useless.  :-)

> I'm guessing the smileys all over the place are conveying your intent that
> funlink() would not work at all, practically speaking...

at least not without caching filenames in the open file table!  ;-)

> GAW> >  You will note that there is no converse
> GAW> > routine, since while name -> ino-dev is unique for each ino-dev, the
> GAW> > reverse is untrue -- consider /foo/bar/.. and /foo, for example...").
> GAW>
> GAW> Yes, that's strictly true, but your example is slightly wrong.  :-)
> 
> I see that's either because they're directories or, more likely what you're
> hinting at, because /foo/bar may be on a different dev than /foo.
> 
> I should say, then, "consider /foo/bar/.. and /foo on the same partition,
> for example...".

I was thinking more along the lines that /foo/bar/.. and /foo/bar refer
to the same directory (assuming /foo/bar isn't a mount point) and of
course all directories have multiple hard links.  Of course you can't
normally/safely unlink() a directory, regardless of whether you refer to
it by its "true" name, or whether you refer to it by its ".." alias
name, but that's a slightly different issue [frmdir()?]  :-)

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