Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re^3: Writing to a file atomically without renaming

by Transient (Hermit)
on Jun 30, 2005 at 20:40 UTC ( #471467=note: print w/replies, xml ) Need Help??

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 }
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 (Abbot) 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.
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.

      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.
        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


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://471467]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (7)
As of 2019-10-14 18:00 GMT
Find Nodes?
    Voting Booth?