Rename bug?

[gordon at sneaky.UUCP]

> >  Then maybe you like the interval between unlink() and link()
> > when your files don't exist. 
> 
> This is completely absurd.  From day 1 on UNIX the way to rename
> files is to link the file to the new name and unlink the old one.
> There is no way to do otherwise (what arguments are you going to
> provide to link?).  There is not now, or ever has been a period of
> time that the file "doesn't exist."  Once a file has no links in

There is a time when no file by the destination filename exists (using
the unlink/link/unlink method).  This is the problem.  The BSD rename()
call is supposed to guarantee that if a file by the destination filename
existed before the call, a file by the destination filename will exist
after the call, and at all times in between.

> UNIX, it requires FSCK or someone very talented at manipulating the
> raw disks to put it back.

Suppose you have a file, say, /etc/passwd.  You make a copy of it, 
/etc/passwd.new, and edit it.  (Let us assume there is locking somehow
to prevent *TWO* people editing /etc/passwd at the same time.  This is
not the issue.  I also do not care about the people who need to re-generate
a hashed database whenever the password file is modified.  This is a 
different problem.)  You need to rename /etc/passwd.new back to /etc/passwd.  
In the process of doing so, /etc/passwd must always exist, so you don't
get all sorts of nasty error messages out of programs trying to use it.
It must always exist, and exist in complete form, so doing a copy
instead of a rename is also unacceptable.