Re^3: 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.

Comment on Re^3: Writing to a file atomically without renaming Download Code

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]
Re^5: Writing to a file atomically without renaming by Transient (Hermit) on Jun 30, 2005 at 23:16 UTC
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]
Re^6: Writing to a file atomically without renaming by waswas-fng (Curate) on Jun 30, 2005 at 23:22 UTC
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]
Re^7: Writing to a file atomically without renaming by Transient (Hermit) on Jul 01, 2005 at 02:45 UTC


Keep It Simple, Stupid
	PerlMonks