in reply to Re^2: Writing to a file atomically without renaming
in thread Writing to a file atomically without renaming

Which is why I suggested making the third copy, which could be "rolled back" in case of a problem. It's similar to DB transactions with redo logs. They don't have to worry about the file permissions problems, though. 

 eval {
 copy file to temp_file
 copy file to backup_file
 modify temp_file
 cat temp_file > file
 verify file is OK
 remove temp_file and backup_file
 };
 if ( $@ ) {
   remove temp_file
   cat backup_file > file
   remove backup_file
 }

[download]
Worst case scenario the cat of the backup_file to temp_file fails and you're left with a corrupt "file" and the extra "backup_file" which would have to be moved back manually.

Replies are listed 'Best First'.
Re^4: Writing to a file atomically without renaming
by salva (Canon) on Jun 30, 2005 at 20:47 UTC
    I think it can be done with three files: the target, a "log" file and a temporary:
    • when starting the program, if the log file exist => cat it to the target and then remove it
    • to modify the file, write the data to a temporary file, them rename the temporary file to be log file, cat the log over the target and finally remove the log file.
[reply]
Re^4: Writing to a file atomically without renaming
by waswas-fng (Curate) on Jun 30, 2005 at 22:38 UTC
    no. worse case is when you are "rolling back" that another user on your multi user system steals the disk space needed for the cat backupfile > file between the time the > zeros file out and the time cat is done -- leaving you with a broken file. That is why the unlink,rename method is popular -- at no time do you destroy the rollback until the new file is in place.


    -Waswas
[reply]
      Your cat must be different than mine..( a cat of a different color?) my "cat backup_file > file" won't destroy both the backup_file and the main file in the event that the backup_file was unable to overwrite the file. A simple diff between the two before removing the backup file is all that would be needed.
[reply]
        backup_file has different perms because you copied the file to a new file as a different user. I am not saying backup_file is gone if you hit that case -- only that you end up in a situation where your app or the other apps that use that file are looking at corrupt data (they don't know about backup_file). cat backup_file > file does the following: 
        trunc file.

# this is where you have the race condition.

redirects the data in backup_file to file.  
closes file

        [download]


        -Waswas
[reply]
[d/l]

In Section Seekers of Perl Wisdom