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

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