Re^5: Writing to a file atomically without renaming

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.

Comment on Re^5: Writing to a file atomically without renaming

Replies are listed 'Best First'.
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
Quite right... which is what I stated here, no argument from me. 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. Although moving the file over is another option in the case that this exception handling fails.. even if it does clobber the options, you can chmod it to at the least be group rw (or whatever it was before). Fin	[reply]