bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mv silently does nothing for hard links


From: Jim Meyering
Subject: Re: mv silently does nothing for hard links
Date: Wed, 02 Apr 2003 18:44:43 +0200

address@hidden wrote:
> mv(1) behaves oddly with hard links.  Create two files which are links to
> the same inode:
>
> % mkdir test
> % cd test
> % touch a
> % ln a b
> % ls
> a  b
>
> Now try mv-ing one to the other:
>
> % mv -v a b && echo yes
> `a' -> `b'
> yes
> % ls
> a  b
...
> (On HP-UX, /bin/mv will report 'a and b are identical', which seems a
> small improvement.)

Thank you for reporting that.
FYI, the same thing would happen with mv from the latest test release:

  ftp://alpha.gnu.org/gnu/coreutils/coreutils-4.5.12.tar.bz2
  (coreutils is the union of fileutils, textutils, and sh-utils)

But the actual behavior is system-dependent, since it relies on
the underlying `rename' system call.  On NetBSD 1.6, I notice that
rename does what I'd expect and so mv unlinks `a' in your example.
But on all of the following, rename does nothing and returns zero:

  OpenBSD 3.2
  Linux-2.4.19, ext3, libc-2.3.1
  OSF1 Tru64 V4.0
  HPUX B10.20
  Solaris 5.8


FYI, the POSIX spec for rename says this:

  If the old argument and the new argument
  resolve to the same existing file, rename( ) shall return successfully
  and perform no other action.

Then, in the rationale:

  The specification that if old and new refer to the same file is intended
  to guarantee that: rename("x", "x"); does not remove the file.

So technically, I suppose the implementations are compliant in that
they comply with the wording of the specification.  But if the goal of
the wording in the specification is solely to ensure the above sentence
from the rationale, then the specification itself is imprecise.

This issue has already been raised, and Andries Brouwer proposed
to improve the wording in the spec, but that was back in 1999:

  http://www.opengroup.org/austin/mailarchives/austin-review-l/msg00048.html

I'll bring this up on the appropriate mailing list.

Jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]