mv: fail when moving a file to a hardlink

We may run into a race condition if we treat hard links to the same file
as distinct files.  If we do 'mv a b' and 'mv b a' in parallel, both a
and b can disappear from the file system.  The reason is that in this
case the unlink on src is called and the system calls can end up being
run in the order where unlink(a) and unlink(b) are the last two system
calls.  Therefore exit with an error code so that we avoid the potential
data loss.

* src/copy.c (same_file_ok): Don't set unlink_src that was used by mv,
and return false for two hardlinks to a file in move_mode.
*src/copy.c (copy_internal): No longer honor the unlink_src option,
used only by mv.
NEWS: Mention the change in behavior.
* tests/cp/same-file.sh: Augment to cover the `cp -a hlsl1 sl1` case.
* tests/mv/hard-verbose.sh: Remove no longer needed test.
* tests/local.mk: Remove the reference to hard-verbose.sh.
* tests/mv/hard-4.sh: Adjust so we fail in this case.
* tests/mv/i-4.sh: Likewise.
* tests/mv/symlink-onto-hardlink-to-self.sh: Likewise.

1 files changed, 7 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index 5fbdc6a4f..6a84c4892 100644
--- a/NEWS
+++ b/NEWS
@@ -30,6 +30,13 @@ GNU coreutils NEWS                                    -*- outline -*-
   dd accepts a new status=progress level to print data transfer statistics
   on stderr approximately every second.
 
+** Changes in behavior
+
+   mv no longer supports moving a file to a hardlink, as currently that
+   is only supported through unlinking the source file.  That's racy
+   in the presence of multiple mv instances, which could result in both
+   hardlinks being deleted.  This feature was added in coreutils-5.0.1.
+
 ** Improvements
 
   cp,install,mv will convert smaller runs of NULs in the input to holes,