[EMAIL PROTECTED] 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 _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
