Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!ninja!sys1!sneaky!gordon From: gordon@sneaky.UUCP Newsgroups: comp.unix.questions Subject: Re: Rename bug? Message-ID: <-64039385@sneaky> Date: 2 Jun 88 21:00:00 GMT References: <9312@eddie.MIT.EDU> Lines: 29 Nf-ID: #R:eddie.MIT.EDU:9312:sneaky:-64039385:000:1562 Nf-From: sneaky.UUCP!gordon Jun 2 16:00:00 1988 > > 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.