bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Meyering
Subject: bug#6960: mv refuses to move a symlink over a hard link to the same file
Date: Wed, 04 Jan 2012 21:53:53 +0100

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]