Subject: Re: funlink() for fun!
To: None <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 07/15/2003 12:40:57
On Tue, 15 Jul 2003 firstname.lastname@example.org wrote:
> On Tue, Jul 15, 2003 at 11:47:20AM -0700, Bill Studenmund wrote:
> > On Mon, 14 Jul 2003, Greg A. Woods wrote:
> > Since the program should (or can) know the path the file should have, let
> > it take care of remembering it. That way only the cases that need this
> > bother with it.
> Not really -- file descriptors inherited from parent processes:
> shell redirections and such.
Yes, but come on, how many programs really really are going to want to
unlink stdin or stdout? Close, yes, but unlink?
> But the problem is not race conditions in world writeable directories
> -- that is already solved. Sticky bits, etc. Don't make mode 777
> directories for temporary files. I can't see why we need a new system
> call either.
What Greg is talking about here is a way a program can make & remove temp
files and know they are gone all by itself. What you're talking about
requires administrative assistance. While it is easy to do, the program
has to trust the admin to have gotten things right.
While I'm not saying get rid of sticky bits and such, I can see the
utility of a call that a program can use to make SURE that a file has been
The only way you can be really sure the path and the file descriptor are
the same is if you do the comparison & removal without unlocking the
vnode. Since we're talking about vnode locks, we're talking about code in
the kernel. Thus a system call. :-)