From b01355a1dc4939a3967ee82ac0a6dd19702778c3 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 1 Feb 2012 21:42:45 +0100 Subject: mv: "mv A B" would sometimes succeed, yet A would remain, ... But only when both A and B were hard links to the same symlink. * src/copy.c (same_file_ok): Handle another special case: the one in which we are moving a symlink onto a hard link to itself. In this case, we must explicitly tell the caller to unlink the source file. Otherwise, at least the linux-3.x kernel rename function would do nothing, as mandated by POSIX 2008. * tests/mv/symlink-onto-hardlink-to-self: New test. * tests/Makefile.am (TESTS): Add it. * NEWS (Bug fixes): Mention it. Reported by Bernhard Voelker in http://bugs.gnu.org/10686 --- NEWS | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'NEWS') diff --git a/NEWS b/NEWS index 9eebbf676..553bb297e 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,12 @@ GNU coreutils NEWS -*- outline -*- referent, there is no risk of data loss, since the symlink will typically still point to one of the hard links. + "mv A B" could succeed, yet A would remain. This would happen only when + both A and B were hard links to the same symlink, and with a kernel for + which rename("A","B") does nothing and returns 0 (POSIX mandates this + surprising rename no-op behavior). Now, mv handles this case by skipping + the usually-useless rename and simply unlinking A. + * Noteworthy changes in release 8.15 (2012-01-06) [stable] -- cgit v1.2.3-54-g00ecf