Eric Blake wrote: > On 01/04/2012 01:32 PM, Anders Kaseorg wrote: >> This refusal makes it impossible to overwrite a hard link with a symlink >> _atomically_. > > It is already impossible to overwrite a directory with a symlink > atomically; then again, the only time rename() allows overwriting a > directory is if it is empty, and removing an empty directory before > putting a symlink in its place is not a form of data loss. 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. > >>> Personally, I prefer the semantics of 'mv -f --backup=numbered' so use a >>> shell alias. >> >> mv --backup=numbered is not atomic; it expands to two rename() syscalls, >> between which the target doesn’t exist at all.
Oh! Amazing that suboptimal behavior has persisted in coreutils for so long. > 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. No "maybe" about it ;-) I was already looking at that. It will be rather hairy, though.
