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