GNU bug report logs - #6960
mv refuses to move a symlink over a hard link to the same file

Previous Next

Package: coreutils;

Reported by: Matt McCutchen <matt <at> mattmccutchen.net>

Date: Tue, 31 Aug 2010 21:27:01 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


Message #37 received at 6960 <at> debbugs.gnu.org (full text, mbox):

From: Anders Kaseorg <andersk <at> MIT.EDU>
To: 6960 <at> debbugs.gnu.org
Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the
	same file
Date: Wed, 4 Jan 2012 15:32:02 -0500 (EST)
This refusal makes it impossible to overwrite a hard link with a symlink 
_atomically_.

See for example http://bugs.debian.org/654596 .

In reply to message #17:
> One may argue that there is no data loss when the destination link count 
> is 2 or more, but once the destination has been unlinked, it may be very 
> challenging to locate another copy.

I would instead argue that there is no data loss when replacing a hard 
link foo with a symlink to bar, as long as foo and bar are _different_ 
hard links to the same inode.  In that case, locating the other copy is 
not a problem because the symlink will still be valid.

For example, in the example from the original report:
  -rw------- 2 matt matt 0 2010-08-31 17:10 New_York
  -rw------- 2 matt matt 0 2010-08-31 17:10 localtime
  lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York
mv may reasonably refuse to overwrite New_York with localtime.new, but it 
should not refuse to overwrite localtime with localtime.new.

> Personally, I prefer the semantics of 'mv -f --backup=numbered' so use a 
> shell alias.

mv --backup=numbered is not atomic; it expands to two rename() syscalls, 
between which the target doesn’t exist at all.

Anders




This bug report was last modified 13 years and 179 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.