Rename bug?

[Leslie Mikesell]

2 Jun 88 05:09:39 GMT
Reply-To: les at chinet.UUCP (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 33

In article <May.31.17.12.57.1988.3256 at topaz.rutgers.edu> ron at 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