On Wed, 4 Jan 2012, Eric Blake wrote: > But whether the inability to atomically overwrite a directory with a > symlink should carry over to a refusal to atomically overwrite a regular > file with a symlink is a different matter.
To be clear, mv is already perfectly happy to atomically overwrite a regular file with a symlink (even if that causes data loss), as long as it doesn’t detect that the symlink points to the same inode. The only purpose given for this same-inode check is preventing a particular kind of accident, and I claim that this purpose would be better served by a same-path check, because the same-inode-but-different-path case is useful and can’t allow that kind of accident (and indeed, won’t lose data at all). > Maybe we should fix that, to make mv --backup use link()/rename() rather > than rename()/rename(), so that there is no window where the target > doesn't exist. Perhaps, but that’s not a good solution to _this_ problem, because a script that wants to do this kind of atomic replacement would then need to go delete the backups (potentially resulting in more data loss). Anders
