http://qs1969.pair.com?node_id=471498


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

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
  • Comment on Re^4: Writing to a file atomically without renaming

Replies are listed 'Best First'.
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.
      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


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