bug#6960: mv refuses to move a symlink over a hard link to the same file

[Jim Meyering]

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.