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. | [reply]
[d/l] |
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] |
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.
| [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] |