Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!chinet!les From: les@chinet.UUCP (Leslie Mikesell) Newsgroups: comp.unix.questions Subject: Re: Rename bug? Message-ID: <5730@chinet.UUCP> Date: 2 Jun 88 05:09:39 GMT Article-I.D.: chinet.5730 References: <9312@eddie.MIT.EDU> <467@aiva.ed.ac.uk> <9341@eddie.MIT.EDU> <2144@rpp386.UUCP> <5702@chinet.UUCP>ron@topaz.rutgers.edu (Ron Natalie) writes: >> 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 >UNIX, it requires FSCK or someone very talented at manipulating the >raw disks to put it back. sigh... I suppose I should have been explicit about the arguments to the unlink() and link() functions, but I thought it was obvious. Given an existing file xx which several people may be reading, and new data in a file TMP4653 that is supposed to replace file xx, and no atomic rename() function, what do you do? It is kind of anti-social to copy on top of a file that someone is reading since they might see part of the old file and part of the new, so you are left with: unlink("xx"); /* anyone who has it open will still see the old file */ link("TMP4653","xx"); /* opening now will get the new file */ unlink("TMP4653"); /* cleanup */ This leaves an interval between unlink("xx") and link("TMP4653","xx") when an attempt to open("xx") will fail. I work with a system that has about 10,000 files on line that are mostly updated daily, some every 10 minutes, and it seems like a real kludge that I had to make the retrieval program attempt open() twice with a sleep() in between to be sure of finding the file. Can it be done otherwise? Les Mikesell