diff options
| author | Jim Meyering <meyering@redhat.com> | 2012-02-01 21:42:45 +0100 |
|---|---|---|
| committer | Jim Meyering <meyering@redhat.com> | 2012-02-12 12:21:53 +0100 |
| commit | b01355a1dc4939a3967ee82ac0a6dd19702778c3 (patch) | |
| tree | a8f6534979bebdda6d60a5985d9a7094322ae95b /NEWS | |
| parent | 31eeead93842c6581e0a9b21f6e8eb964d0c9309 (diff) | |
| download | coreutils-b01355a1dc4939a3967ee82ac0a6dd19702778c3.tar.xz | |
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
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 6 |
1 files changed, 6 insertions, 0 deletions
@@ -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] |