Re: { mv test test; } should not fail

[Jim Meyering]

Krzysztof Żelechowski wrote:
>> At any rate, I don't see any reason for coreutils to change its
>> behavior; although I might be persuaded otherwise if someone writes up a
>> patch (including testsuite and documentation),
>
> Whereas I hoped to be persuaded that failing makes sense and is *not*
> counter-intuitive.  Of course, changing something just because is
> harder than doing it right from the onset (example: Polish
> orthography).
>
>> and in particular, you
>> MUST ensure that coreutils does NOT regress on:
>>
>> ln a b
>> mv a b

In the implementation of mv, it is very easy to make
the subtle, but fatal (to those afflicted) mistake of
allowing the above to result in data loss.  But that is incidental,
because we're talking about the case in which the two arguments
refer not just to the same file, but that are identical strings.

There is also a lot of variation in how systems implement the
rename syscall.  With GNU mv, you get a consistent, and imho,
important failure, insulating applications from the underlying
syscall.  Consistency is a small part of the answer.

Here's the real reason:

I have seen no reason to make "mv a a" a successful no-op,
yet I have seen numerous occasions where GNU mv's implementation
exposed a problem in a script that does e.g., "mv $a $b" or
when someone does "mv foo !$" on the command line.  Not reporting
an error for something so unusual can be fatal if it makes you
think you've just moved a precious file to a safe place and you're
all clear to nuke the containing directory.

> I have observed that in the case { mv a a; } mv does not call rename
> at all, as if trying to be smarter than the operating system.  I am
> curious why it was implemented like this.