Debian Bug report logs - #654666
mv -f refuses to replace a file with a symlink to the same inode

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Jonathan Nieder <[email protected]>

To: [email protected]

Subject: mv -f refuses to replace a file with a symlink to the same inode

Date: Wed, 4 Jan 2012 18:34:12 -0600

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.

Message #14 received at [email protected] (full text, mbox, reply):

From: Jonathan Nieder <[email protected]>

To: [email protected]

Subject: Re: mv -f refuses to replace a file with a symlink to the same inode

Date: Tue, 7 Feb 2012 18:55:48 -0600

Hi,

Jonathan Nieder wrote:

>	echo "some data" >file
>	ln file link
>	ln -s file link.tmp
>	mv -f link.tmp link
>
> I would expect that to succeed.

There's a patch upstream (d1b0155d, "mv: allow moving symlink onto
same-inode dest with >= 2 hard links") that treats the symptoms.
Unfortunately that patch does not solve the full problem: coreutils mv
is still too clever for its own good and is still not compliant with
the (now clarified) POSIX requirements.

Not sure what to do with this bug report.  Maybe it would be worth
tracking "allow replacing a hard link by a symlink" and "use lstat,
not stat, for same-file check, as required by POSIX" separately.

Thanks,
Jonathan

Message #21 received at [email protected] (full text, mbox, reply):

From: Michael Stone <[email protected]>

To: [email protected]

Subject: Re: mv -f refuses to replace a file with a symlink to the same inode

Date: Sun, 20 Apr 2025 13:08:43 -0400

Version: 9.7-1

Send a report that this bug log contains spam.