Your message dated Sun, 20 Apr 2025 13:08:43 -0400
with message-id <[email protected]>
and subject line Re: mv -f refuses to replace a file with a symlink to the same
inode
has caused the Debian Bug report #654666,
regarding mv -f refuses to replace a file with a symlink to the same inode
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
654666: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654666
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: coreutils
Version: 8.5-1
Tags: upstream
Forwarded: http://debbugs.gnu.org/6960
Hi,
I have a hard link that I want to replace with a symlink without
disturbing concurrent tasks:
echo "some data" >file
ln file link
ln -s file link.tmp
mv -f link.tmp link
I would expect that to succeed. Instead:
$ mv -f link.tmp link
mv: `link.tmp' and `link' are the same file
POSIX is somewhat unclear about this situation:
If the source_file operand and destination path name the same
existing file, then the destination path shall not be removed,
and [...]
The crux is what it means to "name the same existing file". As
explained at [1], I believe that passage is not intended to apply to a
symlink and hard link to the same file, but it's hard to be sure.
Aside from POSIX, there are other reasons to want to be able to do
this easily, but that's already well covered in the upstream report.
See http://bugs.debian.org/654596 for context.
Nothing particularly urgent about this; just filing so it doesn't get
forgotten.
Thanks for keeping coreutils working well.
Jonathan
[1] http://austingroupbugs.net/view.php?id=534
If this passage applies to cases where src is a symlink to the same
inode as dst, then a POSIX-compliant mv implementation could act as
though I had written "rm -f link.tmp" instead of "mv ...", which seems
a little insane. Hopefully the Austin group will clarify it soon.
--- End Message ---
--- Begin Message ---
Version: 9.7-1
--- End Message ---
