From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 08:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 10686@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.132808452923439 (code B ref -1); Wed, 01 Feb 2012 08:23:02 +0000 Received: (at submit) by debbugs.gnu.org; 1 Feb 2012 08:22:09 +0000 Received: from localhost ([127.0.0.1]:48120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsVSB-00065y-W3 for submit@debbugs.gnu.org; Wed, 01 Feb 2012 03:22:08 -0500 Received: from eggs.gnu.org ([140.186.70.92]:46854) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsVS8-00065S-6R for submit@debbugs.gnu.org; Wed, 01 Feb 2012 03:22:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsVRd-0005cJ-E6 for submit@debbugs.gnu.org; Wed, 01 Feb 2012 03:21:38 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:51824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsVRd-0005c1-8b for submit@debbugs.gnu.org; Wed, 01 Feb 2012 03:21:33 -0500 Received: from eggs.gnu.org ([140.186.70.92]:41240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsVRQ-0006cS-0h for bug-coreutils@gnu.org; Wed, 01 Feb 2012 03:21:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsVRJ-0005PR-GO for bug-coreutils@gnu.org; Wed, 01 Feb 2012 03:21:19 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:63045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsVRJ-0005OL-7D for bug-coreutils@gnu.org; Wed, 01 Feb 2012 03:21:13 -0500 Received: from [192.168.2.108] (p4FF72B78.dip.t-dialin.net [79.247.43.120]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MgaZf-1SGL8z3gW7-00Ns0W; Wed, 01 Feb 2012 09:21:11 +0100 Message-ID: <4F28F5F5.4030306@bernhard-voelker.de> Date: Wed, 01 Feb 2012 09:21:09 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:PyKlbpO+hHqdV9JmZ4AXMZdazD+xJmMZBVqL3UOC8wy rcanuxUxJ4otglnyb8WS1Cp4PBb9TGsg/tIWXquLgBZziWMp3g N1zR9Lw305QuEYpVhOw3p1+DRsOB3VyNJrU00CK476xJTN28a5 fDaJfbKQ/mu4Mj0K73bnyF40bSeOE5HYgBKKT2jfFdtq3nDkj3 KXo/R7KB24TpxsJ3tG/RqA4k0cnPq/1nknEqx0sWY9J/bTXFEn Cl7MvrDKimCUWsA8aLTyO/79xXviFew0HkKhwa2TqdaM2tZP54 jq7bfhpthY9EMlaFgaT7X4NBFGNlauq/bBCGkFta+kHfS5zi2m MGKcIwuKgREnqLG3Zz1Ua9ESy6ng2wohagB/oouiq X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Playing around with the latest mv checkin, I noticed another corner case: Create a file 'f', a symlink 'l' to it, and then a hardlink 's' to that symlink: $ touch f && ln -s f l && ln l s && ls -ogi total 0 6444 -rw-r--r-- 1 0 Feb 1 08:52 f 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f Trying to mv the hardlink over the symlink seems to succeed: $ ~/git/coreutils/src/mv s l ... but the name 's' was not unlinked: $ ls -ogi total 0 6444 -rw-r--r-- 1 0 Feb 1 08:52 f 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f Using the -v option looks also normal, but is a nop: $ ~/git/coreutils/src/mv -v s l �s� -> �l� $ ls -ogi total 0 6444 -rw-r--r-- 1 0 Feb 1 08:52 f 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f The strace only shows the rename(): stat("l", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 rename("s", "l") = 0 I'd have expected either a) the name 's' to be unlinked, or b) an error message that something was wrong (well, whatever). I'd prefer a) of course. That behaviour didn't change at least since version 7.1 (on openSuSE-11.3), but back in the earlier days in 5.93 (SLES-10.3), 's' disappeared as expected: stat("l", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0 lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 unlink("l") = 0 rename("s", "l") = 0 Does mv now work as specified? Is this a kernel or a coreutils (or a user) issue? Have a nice day, Berny From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 11:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132809664111737 (code B ref 10686); Wed, 01 Feb 2012 11:44:01 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 11:44:01 +0000 Received: from localhost ([127.0.0.1]:48236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsYbY-00033G-EC for submit@debbugs.gnu.org; Wed, 01 Feb 2012 06:44:00 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:55349) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsYbR-00032x-Vs for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 06:43:55 -0500 Received: from [192.168.2.108] (p4FF72B78.dip.t-dialin.net [79.247.43.120]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MYtKV-1S65F71eSJ-00VbvF; Wed, 01 Feb 2012 12:43:26 +0100 Message-ID: <4F29255D.7010107@bernhard-voelker.de> Date: Wed, 01 Feb 2012 12:43:25 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:dvBAWkOwOjuRSGsjd7Msxy+LGc0DIkAtWw/T3ThDCBP /mRCPp3evqD8vjjAF3AOxkd32EBwu/Ry5JRHkc9y0705vc4xUP Qy4gXYsYTZ5oCX8W5cs4C0fICQ5CjhYn0TqNbOC59ldfsmZaKI G4Bi8bC/s/a6VLHZ2jtsW4Ycgq5qi2tIZNCXy9cMO5XyiNPhan 2Pkrxzzh+TSl8tyeXRxixk4q2wsZdeUjcmPsCSRztcdRj2cRcC SNkdQ4wfRltGRaL9bFjql5lYuQ7bDUCBBlI45dKgTgALLnZ8Jt WGqfmqJmqh5Xtnw2IM/WPXFnUQHld9Dk89Cvr0Gwr6pNZ4s8vN TNnRXVk3dOjjJNkmCDP3+4n1tx6WVR6UgvraOm+dF X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02/01/2012 09:21 AM, Bernhard Voelker wrote: > $ touch f && ln -s f l && ln l s && ls -ogi > total 0 > 6444 -rw-r--r-- 1 0 Feb 1 08:52 f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f > > Trying to mv the hardlink over the symlink seems to succeed: > > $ ~/git/coreutils/src/mv s l > > ... but the name 's' was not unlinked: ... > That behaviour didn't change at least since version 7.1 > (on openSuSE-11.3), but back in the earlier days in 5.93 > (SLES-10.3), 's' disappeared as expected: Hmm, looks like commit f1d1ee91217d08527c6bf7682987339e38116268 introduced this in 2006. Have a nice day, Berny From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 12:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Bernhard Voelker Cc: 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132810049120333 (code B ref 10686); Wed, 01 Feb 2012 12:49:02 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 12:48:11 +0000 Received: from localhost ([127.0.0.1]:48291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsZbe-0005Hu-Ld for submit@debbugs.gnu.org; Wed, 01 Feb 2012 07:48:11 -0500 Received: from mx.meyering.net ([88.168.87.75]:55992) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsZbb-0005Hk-II for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 07:48:09 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 1140460096; Wed, 1 Feb 2012 13:47:45 +0100 (CET) From: Jim Meyering In-Reply-To: <4F28F5F5.4030306@bernhard-voelker.de> (Bernhard Voelker's message of "Wed, 01 Feb 2012 09:21:09 +0100") References: <4F28F5F5.4030306@bernhard-voelker.de> Date: Wed, 01 Feb 2012 13:47:44 +0100 Message-ID: <87mx92en4f.fsf@rho.meyering.net> Lines: 119 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Bernhard Voelker wrote: > Playing around with the latest mv checkin, > I noticed another corner case: > > Create a file 'f', a symlink 'l' to it, and > then a hardlink 's' to that symlink: > > $ touch f && ln -s f l && ln l s && ls -ogi > total 0 > 6444 -rw-r--r-- 1 0 Feb 1 08:52 f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f Hi Bernhard, Thanks for the report. Here, you've already gotten into questionable territory, since the idea of a hard link to a symbolic link is not standardized. For example, on FreeBSD 9.0, you cannot even create one: (instead, it hard-links the referent of the symlink) freebsd$ touch f && ln -s f l && ln l s && ls -ogi f l s 1587047 -rw-r--r-- 2 0 Feb 1 04:58 f 1587100 lrwxr-xr-x 1 1 Feb 1 04:58 l -> f 1587047 -rw-r--r-- 2 0 Feb 1 04:58 s > Trying to mv the hardlink over the symlink seems to succeed: > > $ ~/git/coreutils/src/mv s l > > ... but the name 's' was not unlinked: That is definitely undesirable behavior. For now, one possibility is to make "mv" reject that corner case with this diagnostic: mv: 's' and 'l' are the same file Proposed patch below. > $ ls -ogi > total 0 > 6444 -rw-r--r-- 1 0 Feb 1 08:52 f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f > > Using the -v option looks also normal, but is a nop: > > $ ~/git/coreutils/src/mv -v s l > =E2=80=98s=E2=80=99 -> =E2=80=98l=E2=80=99 > $ ls -ogi > total 0 > 6444 -rw-r--r-- 1 0 Feb 1 08:52 f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f > 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f > > The strace only shows the rename(): > > stat("l", {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 > lstat("s", {st_mode=3DS_IFLNK|0777, st_size=3D1, ...}) =3D 0 > lstat("l", {st_mode=3DS_IFLNK|0777, st_size=3D1, ...}) =3D 0 > rename("s", "l") =3D 0 > > > I'd have expected either > a) the name 's' to be unlinked, or > b) an error message that something was wrong (well, whatever). > I'd prefer a) of course. So would I. > That behaviour didn't change at least since version 7.1 > (on openSuSE-11.3), but back in the earlier days in 5.93 > (SLES-10.3), 's' disappeared as expected: > > stat("l", {st_mode=3DS_IFREG|0640, st_size=3D0, ...}) =3D 0 > lstat("s", {st_mode=3DS_IFLNK|0777, st_size=3D1, ...}) =3D 0 > lstat("l", {st_mode=3DS_IFLNK|0777, st_size=3D1, ...}) =3D 0 > unlink("l") =3D 0 > rename("s", "l") =3D 0 > > Does mv now work as specified? Is this a kernel or > a coreutils (or a user) issue? It's a standards and kernel issue. POSIX explicitly says (of rename) If the old argument and the new argument resolve to the same existing file, rename( ) shall return successfully and perform no other action. though that particular wording might be slated to change with POSIX 2008, to allow different (more desirable) behavior. Search the austin-group archives if you need to be sure. Also, I don't know whether the above wording applies to this particular case of two hard links to the same symlink. Again, I think we're in unspecified territory. Here's a proposed patch. This is such an improbable corner case that I think it's not worth trying to fix any other way (either by unlinking the destination or by replacing rename). (of course, if I go with this, I'll insert a big comment justifying this tiny change) diff --git a/src/copy.c b/src/copy.c index 4810de8..78cd8c8 100644 --- a/src/copy.c +++ b/src/copy.c @@ -1229,7 +1229,7 @@ same_file_ok (char const *src_name, struct stat const= *src_sb, know this here IFF preserving symlinks), then it's ok -- as long as they are distinct. */ if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) - return ! same_name (src_name, dst_name); + return ! same_name (src_name, dst_name) && ! same_link; src_sb_link =3D src_sb; dst_sb_link =3D dst_sb; From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 13:57:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132810457626296 (code B ref 10686); Wed, 01 Feb 2012 13:57:04 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 13:56:16 +0000 Received: from localhost ([127.0.0.1]:48398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsafV-0006q1-T1 for submit@debbugs.gnu.org; Wed, 01 Feb 2012 08:56:15 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:65266) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsafP-0006ph-TT for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 08:56:10 -0500 Received: from [192.168.2.108] (p4FF72B78.dip.t-dialin.net [79.247.43.120]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MSVpQ-1S2S0z36MG-00Rx8M; Wed, 01 Feb 2012 14:55:38 +0100 Message-ID: <4F294458.5080005@bernhard-voelker.de> Date: Wed, 01 Feb 2012 14:55:36 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> In-Reply-To: <87mx92en4f.fsf@rho.meyering.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:NZcoqpeKw/br8s+OhJ0gMQGW0kd/LdM2I18CL3Sxj6N pvo9y7sgDiFH4XBmR9LSUPFBQlYzOutnJMPNDnMLnOww/EspZM OwYl7C7wpp+1Zl15bIJZnXgV0amK4HiXxLvFap1R78C5E1d/oJ HHQ2dmzuPVLzGVoHVpfSocsgZiyA+oLtRHFSRRgaRVs+SO92B2 Lx3gwgsdVzffGyXneial0cniXceGbY8KD/4GZUn4FVeiS2jWi6 sbPDE1UNZeQSq6OSL1xOTMEBfVVIUCX4zDHAUJEaPAAHMVpW+W tokdTqZx1BtCao4oCkpKUI51U6xDtxAHO26/IYadNSf9VoevO9 MmIniFu0Ak8xYm06eW66Hwjm6bLHzs9qhtxw8Ur8s X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02/01/2012 01:47 PM, Jim Meyering wrote: > Bernhard Voelker wrote: >> Playing around with the latest mv checkin, >> I noticed another corner case: >> >> Create a file 'f', a symlink 'l' to it, and >> then a hardlink 's' to that symlink: >> >> $ touch f && ln -s f l && ln l s && ls -ogi >> total 0 >> 6444 -rw-r--r-- 1 0 Feb 1 08:52 f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f > > Hi Bernhard, > Thanks for the report. > > Here, you've already gotten into questionable territory, since the > idea of a hard link to a symbolic link is not standardized. > For example, on FreeBSD 9.0, you cannot even create one: > (instead, it hard-links the referent of the symlink) > > freebsd$ touch f && ln -s f l && ln l s && ls -ogi f l s > 1587047 -rw-r--r-- 2 0 Feb 1 04:58 f > 1587100 lrwxr-xr-x 1 1 Feb 1 04:58 l -> f > 1587047 -rw-r--r-- 2 0 Feb 1 04:58 s > >> Trying to mv the hardlink over the symlink seems to succeed: >> >> $ ~/git/coreutils/src/mv s l >> >> ... but the name 's' was not unlinked: > > That is definitely undesirable behavior. > For now, one possibility is to make "mv" reject > that corner case with this diagnostic: > > mv: 's' and 'l' are the same file > > Proposed patch below. > >> $ ls -ogi >> total 0 >> 6444 -rw-r--r-- 1 0 Feb 1 08:52 f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f >> >> Using the -v option looks also normal, but is a nop: >> >> $ ~/git/coreutils/src/mv -v s l >> ‘s’ -> ‘l’ >> $ ls -ogi >> total 0 >> 6444 -rw-r--r-- 1 0 Feb 1 08:52 f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f >> >> The strace only shows the rename(): >> >> stat("l", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 >> lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 >> lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 >> rename("s", "l") = 0 >> >> >> I'd have expected either >> a) the name 's' to be unlinked, or >> b) an error message that something was wrong (well, whatever). >> I'd prefer a) of course. > > So would I. > >> That behaviour didn't change at least since version 7.1 >> (on openSuSE-11.3), but back in the earlier days in 5.93 >> (SLES-10.3), 's' disappeared as expected: >> >> stat("l", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0 >> lstat("s", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 >> lstat("l", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0 >> unlink("l") = 0 >> rename("s", "l") = 0 >> >> Does mv now work as specified? Is this a kernel or >> a coreutils (or a user) issue? > > It's a standards and kernel issue. > POSIX explicitly says (of rename) > > If the old argument and the new argument resolve to the same existing > file, rename( ) shall return successfully and perform no other action. > > though that particular wording might be slated to change with POSIX 2008, > to allow different (more desirable) behavior. Search the austin-group > archives if you need to be sure. > > Also, I don't know whether the above wording applies to this particular > case of two hard links to the same symlink. Again, I think we're in > unspecified territory. > > Here's a proposed patch. > This is such an improbable corner case that I think it's not worth trying > to fix any other way (either by unlinking the destination or by > replacing rename). > > (of course, if I go with this, I'll insert a big comment justifying > this tiny change) > > diff --git a/src/copy.c b/src/copy.c > index 4810de8..78cd8c8 100644 > --- a/src/copy.c > +++ b/src/copy.c > @@ -1229,7 +1229,7 @@ same_file_ok (char const *src_name, struct stat const *src_sb, > know this here IFF preserving symlinks), then it's ok -- as long > as they are distinct. */ > if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) > - return ! same_name (src_name, dst_name); > + return ! same_name (src_name, dst_name) && ! same_link; > > src_sb_link = src_sb; > dst_sb_link = dst_sb; Hi Jim, well, if it's not standardized (yet), then I agree with you that we should choose the simpler b) alternative. Do you think it's work thinking about the -f case? $ ~/git/coreutils/src/mv -f s l /home/berny/git/coreutils/src/mv: ‘s’ and ‘l’ are the same file The info pages are not quite clear in which cases mv tries to overwrite the destination. Usually, I am tempted to think that a "--force" will "just do it" - regardless of data loss. But in this case, mv "just does not" and the only thing left is to rm that hardlink. That makes me think that the implementation of the a) alternative just reduces to calling unlink() ... ;-) Have a nice day, Berny From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 14:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Bernhard Voelker Cc: 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132810497526929 (code B ref 10686); Wed, 01 Feb 2012 14:03:02 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 14:02:55 +0000 Received: from localhost ([127.0.0.1]:48408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rsaly-00070H-Hw for submit@debbugs.gnu.org; Wed, 01 Feb 2012 09:02:54 -0500 Received: from mx.meyering.net ([88.168.87.75]:56211) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rsalv-000706-3L for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 09:02:52 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 123F560125; Wed, 1 Feb 2012 15:02:28 +0100 (CET) From: Jim Meyering In-Reply-To: <4F294458.5080005@bernhard-voelker.de> (Bernhard Voelker's message of "Wed, 01 Feb 2012 14:55:36 +0100") References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F294458.5080005@bernhard-voelker.de> Date: Wed, 01 Feb 2012 15:02:27 +0100 Message-ID: <87bopid53g.fsf@rho.meyering.net> Lines: 36 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Bernhard Voelker wrote: ... > well, if it's not standardized (yet), then I agree with you that we > should choose the simpler b) alternative. > > Do you think it's work thinking about the -f case? > > $ ~/git/coreutils/src/mv -f s l > /home/berny/git/coreutils/src/mv: =E2=80=98s=E2=80=99 and =E2=80=98l=E2= =80=99 are the same file mv's -f option is unrelated to this case. It relates solely to controlling whether one is prompted due to permissions or -i. >From 'info mv's description of the common case (no options): If a destination file exists but is normally unwritable, standard input is a terminal, and the `-f' or `--force' option is not given, `mv' prompts the user for whether to replace the file. (You might own the file, or have write permission on its directory.) If the response is not affirmative, the file is skipped. Yes, it is unfortunate that the standards-imposed semantics of -f is different from what we'd expect. > The info pages are not quite clear in which cases mv tries to > overwrite the destination. Usually, I am tempted to think that > a "--force" will "just do it" - regardless of data loss. > But in this case, mv "just does not" and the only thing left > is to rm that hardlink. If the above is still not clear, please suggest how to improve it. > That makes me think that the implementation of the a) alternative > just reduces to calling unlink() ... ;-) From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 14:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132810646529330 (code B ref 10686); Wed, 01 Feb 2012 14:28:01 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 14:27:45 +0000 Received: from localhost ([127.0.0.1]:48470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsbA0-0007d0-CV for submit@debbugs.gnu.org; Wed, 01 Feb 2012 09:27:44 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:52988) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rsb9v-0007cl-Ga for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 09:27:41 -0500 Received: from [192.168.2.108] (p4FF72B78.dip.t-dialin.net [79.247.43.120]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M2M3o-1SkZFS2X1I-00s90R; Wed, 01 Feb 2012 15:27:11 +0100 Message-ID: <4F294BBD.90109@bernhard-voelker.de> Date: Wed, 01 Feb 2012 15:27:09 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F294458.5080005@bernhard-voelker.de> <87bopid53g.fsf@rho.meyering.net> In-Reply-To: <87bopid53g.fsf@rho.meyering.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:ulSzq4ncCR8xuWpyvZLl3pIgMNsCS31ljlt6vEWE4/3 ADja3QV0NK9ezP5Zc/o2tPyml5tvvoSWxNYJBXB/UVf9VTjKCK Kq/goEkRQPfuS50047z8NJDWtGCVxXggUnDEdZXduEYD73bdIy Bflu5YZTMk1Vf2lBla5NAayixzuC5OSJMxEa3Cnwg7jJ40h36B J8Ct9ThPWOLO/P98FvJZAPzARNgjVE+I8bPmiM4JmfOpOvX+f3 AXol4++2bUSmvqAaCtrd/affW3ghHUhpraDMR36xRBhnTuHQPa 8zmaF/cBVD0G4A6/X9LOOa+5gu2IztPxU0iYu2RpDtpYRbNzzz 7Jha3Q+7O7Pf4TT4jcAZAUU8ML131HOicLRMRsSkj X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02/01/2012 03:02 PM, Jim Meyering wrote: > Bernhard Voelker wrote: > ... >> well, if it's not standardized (yet), then I agree with you that we >> should choose the simpler b) alternative. >> >> Do you think it's work thinking about the -f case? >> >> $ ~/git/coreutils/src/mv -f s l >> /home/berny/git/coreutils/src/mv: ‘s’ and ‘l’ are the same file > > mv's -f option is unrelated to this case. > It relates solely to controlling whether one is prompted > due to permissions or -i. > > From 'info mv's description of the common case (no options): > > If a destination file exists but is normally unwritable, standard > input is a terminal, and the `-f' or `--force' option is not given, > `mv' prompts the user for whether to replace the file. (You might own > the file, or have write permission on its directory.) If the response > is not affirmative, the file is skipped. > > > Yes, it is unfortunate that the standards-imposed semantics > of -f is different from what we'd expect. > > If the above is still not clear, please suggest how to improve it. Well, if permissions are the only case when mv would require confirmation or -f, then it should be added to mv's description. Additionally, the info page might also have note in which cases mv will refuse to work, e.g. when "‘s’ and ‘l’ are the same file". As I'm not sure (anymore) about both, I cannot propose a wording. >> That makes me think that the implementation of the a) alternative >> just reduces to calling unlink() ... ;-) This hardlink-to-softlink case is IMHO identical to the normal hardlinks case (in which mv just unlinks the source): $ touch f1 && ln f1 f2 && ls -ogi f1 f2 6590 -rw-r--r-- 2 0 Feb 1 15:17 f1 6590 -rw-r--r-- 2 0 Feb 1 15:17 f2 $ ~/git/coreutils/src/mv f1 f2 $ ls -ogi f1 f2 ls: cannot access f1: No such file or directory 6590 -rw-r--r-- 1 0 Feb 1 15:17 f2 Therefore, I'd tend to a) again. It doesn't matter if src is a regular file or a symlink. What do you think? Have a nice day, Berny From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 15:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: Bernhard Voelker , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.13281085023755 (code B ref 10686); Wed, 01 Feb 2012 15:02:02 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 15:01:42 +0000 Received: from localhost ([127.0.0.1]:49309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rsbgs-0000yV-3L for submit@debbugs.gnu.org; Wed, 01 Feb 2012 10:01:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13518) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rsbgn-0000yI-5L for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 10:01:39 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q11F174s028199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Feb 2012 10:01:07 -0500 Received: from [10.3.113.27] (ovpn-113-27.phx2.redhat.com [10.3.113.27]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q11F16lU017267; Wed, 1 Feb 2012 10:01:06 -0500 Message-ID: <4F2953B1.4000903@redhat.com> Date: Wed, 01 Feb 2012 08:01:05 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> In-Reply-To: <87mx92en4f.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9B92BE7DCC12E2DEE7EBB7B9" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9B92BE7DCC12E2DEE7EBB7B9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/01/2012 05:47 AM, Jim Meyering wrote: > Bernhard Voelker wrote: >> Playing around with the latest mv checkin, >> I noticed another corner case: >> >> Create a file 'f', a symlink 'l' to it, and >> then a hardlink 's' to that symlink: >> >> $ touch f && ln -s f l && ln l s && ls -ogi >> total 0 >> 6444 -rw-r--r-- 1 0 Feb 1 08:52 f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f >> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f >=20 > Hi Bernhard, > Thanks for the report. >=20 > Here, you've already gotten into questionable territory, since the > idea of a hard link to a symbolic link is not standardized. Actually, POSIX 2008 _did_ standardize the notion of a hard link to a symlink, thanks to linkat(). > For example, on FreeBSD 9.0, you cannot even create one: That's a POSIX-compliance bug in FreeBSD. In that case, the best we can do is emulate it by creating a new symlink with identical contents and owner and as much of the timestamp as lutimens will allow. >=20 > It's a standards and kernel issue. > POSIX explicitly says (of rename) >=20 > If the old argument and the new argument resolve to the same existi= ng > file, rename( ) shall return successfully and perform no other acti= on. >=20 > though that particular wording might be slated to change with POSIX 200= 8, > to allow different (more desirable) behavior. Search the austin-group > archives if you need to be sure. The wording for rename(2) did not change, but the wording for mv(1) _did_ change to allow slightly more desirable behavior. Here's the latest wording, as modified by the latest bug report: http://austingroupbugs.net/view.php?id=3D534 If the source_file operand and destination path resolve to either the same existing directory entry or different directory entries for the same existing file, then the destination path shall not be removed, and one of the following shall occur: a. No change is made to source_file, no error occurs, and no diagnostic is issued. b. No change is made to source_file, a diagnostic is issued to standard error identifying the two names, and the exit status is affected. c. If the source_file operand and destination path name distinct directory entries, then the source_file operand is removed, no error occurs, and no diagnostic is issued. The mv utility shall do nothing more with the current source_file, and go on to any remaining source_files. > Also, I don't know whether the above wording applies to this particular= > case of two hard links to the same symlink. Again, I think we're in > unspecified territory. POSIX actually specifies this quite well - two hardlinks to the same symlink qualify as an instance of two file names that resolve to the same inode after path resolution as checked with lstat(). --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig9B92BE7DCC12E2DEE7EBB7B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPKVOyAAoJEKeha0olJ0NqC7AH/0UbjngCAb9vi/aW3L47qC0F DPBZPwwyczkOcoWPOTJ/wIf4xG4/By7Oa4e5KjUUChnKlBZUf2wQ5pIi1MS+FHCJ Cw3HbKOXxT7hvGIf09MgpiVc191JMNQ/UAG/BzyXzI1kYF0YdvhyvMH/TWPJtjw9 4ocpHf5d5pcK3uJtsVcR4T9WFv+AZU/AEljJiWdltKDD0fMUqfNgWoz8TNNdK3T9 S4++5AcRXRIx+/71WIC9JBGLW6fM+/t/pW67k4H7WcLnVzhhMPZ53nPWGqJAYIr6 VEpMUWe9phSqQk4KWAev45lXdUZbuN0/9AZCnR9G5LeGDRREEBPvzAj8tRdC7q4= =uckB -----END PGP SIGNATURE----- --------------enig9B92BE7DCC12E2DEE7EBB7B9-- From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 15:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: Bernhard Voelker , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.13281111397884 (code B ref 10686); Wed, 01 Feb 2012 15:46:02 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 15:45:39 +0000 Received: from localhost ([127.0.0.1]:49340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RscNO-000234-2v for submit@debbugs.gnu.org; Wed, 01 Feb 2012 10:45:38 -0500 Received: from mx.meyering.net ([88.168.87.75]:56490) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RscNF-00022r-KY for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 10:45:34 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id DF529600A5; Wed, 1 Feb 2012 16:45:06 +0100 (CET) From: Jim Meyering In-Reply-To: <4F2953B1.4000903@redhat.com> (Eric Blake's message of "Wed, 01 Feb 2012 08:01:05 -0700") References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> Date: Wed, 01 Feb 2012 16:45:06 +0100 Message-ID: <87wr86blrx.fsf@rho.meyering.net> Lines: 99 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eric Blake wrote: > On 02/01/2012 05:47 AM, Jim Meyering wrote: >> Bernhard Voelker wrote: >>> Playing around with the latest mv checkin, >>> I noticed another corner case: >>> >>> Create a file 'f', a symlink 'l' to it, and >>> then a hardlink 's' to that symlink: >>> >>> $ touch f && ln -s f l && ln l s && ls -ogi >>> total 0 >>> 6444 -rw-r--r-- 1 0 Feb 1 08:52 f >>> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f >>> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f >> >> Hi Bernhard, >> Thanks for the report. >> >> Here, you've already gotten into questionable territory, since the >> idea of a hard link to a symbolic link is not standardized. > > Actually, POSIX 2008 _did_ standardize the notion of a hard link to a > symlink, thanks to linkat(). > >> For example, on FreeBSD 9.0, you cannot even create one: > > That's a POSIX-compliance bug in FreeBSD. In that case, the best we can > do is emulate it by creating a new symlink with identical contents and > owner and as much of the timestamp as lutimens will allow. > >> >> It's a standards and kernel issue. >> POSIX explicitly says (of rename) >> >> If the old argument and the new argument resolve to the same existing >> file, rename( ) shall return successfully and perform no other action. >> >> though that particular wording might be slated to change with POSIX 2008, >> to allow different (more desirable) behavior. Search the austin-group >> archives if you need to be sure. > > The wording for rename(2) did not change, but the wording for mv(1) > _did_ change to allow slightly more desirable behavior. Here's the > latest wording, as modified by the latest bug report: > > http://austingroupbugs.net/view.php?id=534 > > If the source_file operand and destination path resolve to either the > same existing directory entry or different directory entries for the > same existing file, then the destination path shall not be removed, and > one of the following shall occur: > a. No change is made to source_file, no error occurs, and no diagnostic > is issued. > b. No change is made to source_file, a diagnostic is issued to standard > error identifying the two names, and the exit status is affected. > c. If the source_file operand and destination path name distinct > directory entries, then the source_file operand is removed, no error > occurs, and no diagnostic is issued. > > The mv utility shall do nothing more with the current source_file, and > go on to any remaining source_files. > >> Also, I don't know whether the above wording applies to this particular >> case of two hard links to the same symlink. Again, I think we're in >> unspecified territory. > > POSIX actually specifies this quite well - two hardlinks to the same > symlink qualify as an instance of two file names that resolve to the > same inode after path resolution as checked with lstat(). Thanks for the clarification and quotes, Eric. Bernhard, here's a better patch. With it, mv simply unlinks the "s" in your example: diff --git a/src/copy.c b/src/copy.c index 4810de8..73f5cc5 100644 --- a/src/copy.c +++ b/src/copy.c @@ -1229,7 +1229,17 @@ same_file_ok (char const *src_name, struct stat const *src_sb, know this here IFF preserving symlinks), then it's ok -- as long as they are distinct. */ if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) - return ! same_name (src_name, dst_name); + { + bool sn = same_name (src_name, dst_name); + if ( ! sn && same_link) + { + *unlink_src = true; + *return_now = true; + return true; + } + + return ! sn; + } src_sb_link = src_sb; dst_sb_link = dst_sb; From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 16:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: Eric Blake , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132811268610218 (code B ref 10686); Wed, 01 Feb 2012 16:12:01 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 16:11:26 +0000 Received: from localhost ([127.0.0.1]:49367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RscmL-0002ek-Ap for submit@debbugs.gnu.org; Wed, 01 Feb 2012 11:11:26 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:62624) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RscmA-0002eL-VD for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 11:11:24 -0500 Received: from [192.168.2.108] (p4FF72B78.dip.t-dialin.net [79.247.43.120]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MORLZ-1RxrZA1Jif-005pG8; Wed, 01 Feb 2012 17:10:46 +0100 Message-ID: <4F296401.5000202@bernhard-voelker.de> Date: Wed, 01 Feb 2012 17:10:41 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> In-Reply-To: <87wr86blrx.fsf@rho.meyering.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ZAV79tHLu7Pxc9/inWcvY4+5qEUgPjBBITnUktFnxx6 PuoQRwO79Iv7uFKN0R89IJQmJlXSsY9ilRwvadO/8bDqdLkrBW 4+lO9PUwkR9fW/khUaRRrMLcChg+sNmmDIvm9Afc7tuGvy0FUW C38k2dck6/zor/oQDxN/LZGOanHWtyk4YCvv2ZiuI6vE5MXDTB DGkLMQ/q1Vug0anbtaGV6xrEYWGSrJZZs66hXynQiFa8NhsA/0 HmM5uLWY7NwUjggUxTt+znfJAmctskEvjhmTsJHuddzDJ15ld4 cwQcdk7QhkWReMrxDWp2rpKRPUOWYuyWqlPJPW8C8ZoXPhxeir 3LhOnGlovM+mrPnF6UMxF2NLavsPOuw6cJvKdxtMv X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02/01/2012 04:45 PM, Jim Meyering wrote: > Thanks for the clarification and quotes, Eric. > > Bernhard, here's a better patch. > With it, mv simply unlinks the "s" in your example: > > diff --git a/src/copy.c b/src/copy.c > index 4810de8..73f5cc5 100644 > --- a/src/copy.c > +++ b/src/copy.c > @@ -1229,7 +1229,17 @@ same_file_ok (char const *src_name, struct stat const *src_sb, > know this here IFF preserving symlinks), then it's ok -- as long > as they are distinct. */ > if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) > - return ! same_name (src_name, dst_name); > + { > + bool sn = same_name (src_name, dst_name); > + if ( ! sn && same_link) > + { > + *unlink_src = true; > + *return_now = true; > + return true; > + } > + > + return ! sn; > + } > > src_sb_link = src_sb; > dst_sb_link = dst_sb; Thank you both. The patch works. I wonder if just removing the x->hard_link constraint at the beginning of same_file_ok() would alsoo do (although the comment sounds like this is no good idea): @@ -1213,11 +1213,11 @@ same_file_ok (char const *src_name, struct stat const *src_sb, /* FIXME: this should (at the very least) be moved into the following if-block. More likely, it should be removed, because it inhibits making backups. But removing it will result in a change in behavior that will probably have to be documented -- and tests will have to be updated. */ - if (same && x->hard_link) + if (same) { *return_now = true; return true; } Please don't think I just want to give you more work, but I think this deserves a new test, doesn't it? Have a nice day, Berny From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 01 Feb 2012 16:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Bernhard Voelker Cc: Eric Blake , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132811319311005 (code B ref 10686); Wed, 01 Feb 2012 16:20:02 +0000 Received: (at 10686) by debbugs.gnu.org; 1 Feb 2012 16:19:53 +0000 Received: from localhost ([127.0.0.1]:49377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RscuX-0002rS-54 for submit@debbugs.gnu.org; Wed, 01 Feb 2012 11:19:53 -0500 Received: from mx.meyering.net ([88.168.87.75]:56595) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RscuU-0002rI-G4 for 10686@debbugs.gnu.org; Wed, 01 Feb 2012 11:19:52 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 1A0F760057; Wed, 1 Feb 2012 17:19:26 +0100 (CET) From: Jim Meyering In-Reply-To: <4F296401.5000202@bernhard-voelker.de> (Bernhard Voelker's message of "Wed, 01 Feb 2012 17:10:41 +0100") References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> <4F296401.5000202@bernhard-voelker.de> Date: Wed, 01 Feb 2012 17:19:26 +0100 Message-ID: <87mx92bk6p.fsf@rho.meyering.net> Lines: 66 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Bernhard Voelker wrote: > On 02/01/2012 04:45 PM, Jim Meyering wrote: >> Thanks for the clarification and quotes, Eric. >> >> Bernhard, here's a better patch. >> With it, mv simply unlinks the "s" in your example: >> >> diff --git a/src/copy.c b/src/copy.c >> index 4810de8..73f5cc5 100644 >> --- a/src/copy.c >> +++ b/src/copy.c >> @@ -1229,7 +1229,17 @@ same_file_ok (char const *src_name, struct stat const *src_sb, >> know this here IFF preserving symlinks), then it's ok -- as long >> as they are distinct. */ >> if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) >> - return ! same_name (src_name, dst_name); >> + { >> + bool sn = same_name (src_name, dst_name); >> + if ( ! sn && same_link) >> + { >> + *unlink_src = true; >> + *return_now = true; >> + return true; >> + } >> + >> + return ! sn; >> + } >> >> src_sb_link = src_sb; >> dst_sb_link = dst_sb; > > Thank you both. > The patch works. > > I wonder if just removing the x->hard_link constraint at the beginning > of same_file_ok() would alsoo do (although the comment sounds like this > is no good idea): > > @@ -1213,11 +1213,11 @@ same_file_ok (char const *src_name, struct stat const *src_sb, > /* FIXME: this should (at the very least) be moved into the following > if-block. More likely, it should be removed, because it inhibits > making backups. But removing it will result in a change in behavior > that will probably have to be documented -- and tests will have to > be updated. */ > - if (same && x->hard_link) > + if (same) I doubt that would work (it doesn't set *unlink_src) -- though you're welcome to try it. Even if it did, I'd prefer not to put a change like this in code that might be considered for removal. > *return_now = true; > return true; > } > > Please don't think I just want to give you more work, > but I think this deserves a new test, doesn't it? Of course ;-) That was not a complete patch by a long shot. It didn't even have a commit log. You obviously know by now that any change like this absolutely requires an addition to the tests suite. And since (thanks to Eric's clarification) it does officially count as a bug fix, I'll write a NEWS entry, too. Thanks again for spotting the problem. From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 04 Feb 2012 15:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: Bernhard Voelker , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132837059410327 (code B ref 10686); Sat, 04 Feb 2012 15:50:02 +0000 Received: (at 10686) by debbugs.gnu.org; 4 Feb 2012 15:49:54 +0000 Received: from localhost ([127.0.0.1]:54425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rths5-0002gQ-Hs for submit@debbugs.gnu.org; Sat, 04 Feb 2012 10:49:53 -0500 Received: from mx.meyering.net ([88.168.87.75]:39035) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rthrz-0002gE-4M for 10686@debbugs.gnu.org; Sat, 04 Feb 2012 10:49:47 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id F1E20600B3; Sat, 4 Feb 2012 16:49:02 +0100 (CET) From: Jim Meyering In-Reply-To: <87wr86blrx.fsf@rho.meyering.net> (Jim Meyering's message of "Wed, 01 Feb 2012 16:45:06 +0100") References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> Date: Sat, 04 Feb 2012 16:49:02 +0100 Message-ID: <87fweqvbtd.fsf@rho.meyering.net> Lines: 257 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Jim Meyering wrote: > Eric Blake wrote: > >> On 02/01/2012 05:47 AM, Jim Meyering wrote: >>> Bernhard Voelker wrote: >>>> Playing around with the latest mv checkin, >>>> I noticed another corner case: >>>> >>>> Create a file 'f', a symlink 'l' to it, and >>>> then a hardlink 's' to that symlink: >>>> >>>> $ touch f && ln -s f l && ln l s && ls -ogi >>>> total 0 >>>> 6444 -rw-r--r-- 1 0 Feb 1 08:52 f >>>> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 l -> f >>>> 6462 lrwxrwxrwx 2 1 Feb 1 08:52 s -> f >>> >>> Hi Bernhard, >>> Thanks for the report. >>> >>> Here, you've already gotten into questionable territory, since the >>> idea of a hard link to a symbolic link is not standardized. >> >> Actually, POSIX 2008 _did_ standardize the notion of a hard link to a >> symlink, thanks to linkat(). >> >>> For example, on FreeBSD 9.0, you cannot even create one: >> >> That's a POSIX-compliance bug in FreeBSD. In that case, the best we can >> do is emulate it by creating a new symlink with identical contents and >> owner and as much of the timestamp as lutimens will allow. >> >>> >>> It's a standards and kernel issue. >>> POSIX explicitly says (of rename) >>> >>> If the old argument and the new argument resolve to the same existing >>> file, rename( ) shall return successfully and perform no other action. >>> >>> though that particular wording might be slated to change with POSIX 2008, >>> to allow different (more desirable) behavior. Search the austin-group >>> archives if you need to be sure. >> >> The wording for rename(2) did not change, but the wording for mv(1) >> _did_ change to allow slightly more desirable behavior. Here's the >> latest wording, as modified by the latest bug report: >> >> http://austingroupbugs.net/view.php?id=534 >> >> If the source_file operand and destination path resolve to either the >> same existing directory entry or different directory entries for the >> same existing file, then the destination path shall not be removed, and >> one of the following shall occur: >> a. No change is made to source_file, no error occurs, and no diagnostic >> is issued. >> b. No change is made to source_file, a diagnostic is issued to standard >> error identifying the two names, and the exit status is affected. >> c. If the source_file operand and destination path name distinct >> directory entries, then the source_file operand is removed, no error >> occurs, and no diagnostic is issued. >> >> The mv utility shall do nothing more with the current source_file, and >> go on to any remaining source_files. >> >>> Also, I don't know whether the above wording applies to this particular >>> case of two hard links to the same symlink. Again, I think we're in >>> unspecified territory. >> >> POSIX actually specifies this quite well - two hardlinks to the same >> symlink qualify as an instance of two file names that resolve to the >> same inode after path resolution as checked with lstat(). > > Thanks for the clarification and quotes, Eric. > > Bernhard, here's a better patch. > With it, mv simply unlinks the "s" in your example: > > diff --git a/src/copy.c b/src/copy.c > index 4810de8..73f5cc5 100644 > --- a/src/copy.c > +++ b/src/copy.c > @@ -1229,7 +1229,17 @@ same_file_ok (char const *src_name, struct stat const *src_sb, > know this here IFF preserving symlinks), then it's ok -- as long > as they are distinct. */ > if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) > - return ! same_name (src_name, dst_name); > + { > + bool sn = same_name (src_name, dst_name); > + if ( ! sn && same_link) > + { > + *unlink_src = true; > + *return_now = true; > + return true; > + } > + > + return ! sn; > + } The above wasn't quite right in that it failed to honor mv's --backup option. mv --backup s f would not have created the required backup file. I've adjusted it to fix that, and added tests to cover both cases. This is still not quite ready (i.e., the FIXME comment, where I'll add some explanation), but otherwise should be fine. >From 646456b8ce053b85d30174462620492df648e0e2 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 1 Feb 2012 21:42:45 +0100 Subject: [PATCH] mv: "mv A B" would sometimes succeed, yet A would remain, ... But only when both A and B were hard links to the same symlink. * src/copy.c (same_file_ok): Handle another special case: the one in which we are moving a symlink onto a hard link to itself. In this case, we must explicitly tell the caller to unlink the source file. Otherwise, at least the linux-3.x kernel rename function would do nothing, as mandated by POSIX 2008. * tests/mv/symlink-onto-hardlink-to-self: New test. * tests/Makefile.am (TESTS): Add it. * NEWS (Bug fixes): Mention it. Reported by Bernhard Voelker in http://bugs.gnu.org/10686 --- NEWS | 5 +++ src/copy.c | 26 ++++++++++++++-- tests/Makefile.am | 1 + tests/mv/symlink-onto-hardlink-to-self | 53 ++++++++++++++++++++++++++++++++ 4 files changed, 82 insertions(+), 3 deletions(-) create mode 100755 tests/mv/symlink-onto-hardlink-to-self diff --git a/NEWS b/NEWS index 9eebbf6..ca8c0b5 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,11 @@ GNU coreutils NEWS -*- outline -*- referent, there is no risk of data loss, since the symlink will typically still point to one of the hard links. + "mv A B" could succeed, yet A would remain. This would happen only when + both A and B were hard links to the same symlink, and with a kernel for + which rename("A","B") would do nothing and return 0. Now, in this + unusual case, mv does not call rename, and instead simply unlinks A. + * Noteworthy changes in release 8.15 (2012-01-06) [stable] diff --git a/src/copy.c b/src/copy.c index 4810de8..0764b8e 100644 --- a/src/copy.c +++ b/src/copy.c @@ -1226,10 +1226,30 @@ same_file_ok (char const *src_name, struct stat const *src_sb, same_link = same; /* If both the source and destination files are symlinks (and we'll - know this here IFF preserving symlinks), then it's ok -- as long - as they are distinct. */ + know this here IFF preserving symlinks), then it's usually ok + when they are distinct. */ if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) - return ! same_name (src_name, dst_name); + { + bool sn = same_name (src_name, dst_name); + if ( ! sn) + { + /* It's fine when we're making any type of backup. */ + if (x->backup_type != no_backups) + return true; + + /* This is an unusual case. + FIXME: explain + */ + if (same_link) + { + *unlink_src = true; + *return_now = true; + return true; + } + } + + return ! sn; + } src_sb_link = src_sb; dst_sb_link = dst_sb; diff --git a/tests/Makefile.am b/tests/Makefile.am index a94aaa2..c951f69 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -492,6 +492,7 @@ TESTS = \ mv/partition-perm \ mv/perm-1 \ mv/symlink-onto-hardlink \ + mv/symlink-onto-hardlink-to-self \ mv/to-symlink \ mv/trailing-slash \ mv/update \ diff --git a/tests/mv/symlink-onto-hardlink-to-self b/tests/mv/symlink-onto-hardlink-to-self new file mode 100755 index 0000000..c8adc0b --- /dev/null +++ b/tests/mv/symlink-onto-hardlink-to-self @@ -0,0 +1,53 @@ +#!/bin/sh +# Demonstrate that when moving a symlink onto a hardlink-to-that-symlink, the +# source symlink is removed. Depending on your kernel (e.g., with the linux +# kernel), prior to coreutils-8.16, the mv would successfully perform a no-op. +# I.e., surprisingly, mv s1 s2 would succeed, yet fail to remove s1. + +# Copyright (C) 2012 Free Software Foundation, Inc. + +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +. "${srcdir=.}/init.sh"; path_prepend_ ../src +print_ver_ mv + +# Create a file f, and a symlink s1 to that file. +touch f || framework_failure_ +ln -s f s2 || framework_failure_ + +for opt in '' --backup; do + + # Attempt to create a hard link to that symlink. + # On some systems, it's not possible: they create a hard link to the referent. + ln s2 s1 || framework_failure_ + + # If s1 is not a symlink, skip this test. + test -h s1 \ + || skip_ your kernel or file system cannot create a hard link to a symlink + + mv $opt s1 s2 > out 2>&1 || fail=1 + compare /dev/null out || fail=1 + + # Ensure that s1 is gone. + test -e s1 && fail=1 + + # With --backup, ensure that the backup file was created. + if test "$opt" = --backup; then + ref=$(readlink s2~) || fail=1 + test "$ref" = f || fail=1 + fi + +done + +Exit $fail -- 1.7.9.112.gb85f2 From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 06 Feb 2012 14:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: Eric Blake , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132853919219357 (code B ref 10686); Mon, 06 Feb 2012 14:40:01 +0000 Received: (at 10686) by debbugs.gnu.org; 6 Feb 2012 14:39:52 +0000 Received: from localhost ([127.0.0.1]:56590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuPjT-00052A-HR for submit@debbugs.gnu.org; Mon, 06 Feb 2012 09:39:51 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]:63786) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuPjR-00051x-6X for 10686@debbugs.gnu.org; Mon, 06 Feb 2012 09:39:50 -0500 Received: from [192.168.2.108] (p4FF74D39.dip.t-dialin.net [79.247.77.57]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LckK3-1SIiAa2X95-00jlIX; Mon, 06 Feb 2012 15:38:47 +0100 Message-ID: <4F2FE5F6.1010902@bernhard-voelker.de> Date: Mon, 06 Feb 2012 15:38:46 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> <87fweqvbtd.fsf@rho.meyering.net> In-Reply-To: <87fweqvbtd.fsf@rho.meyering.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:80EnzJGZvcjlWs1Drxr2WsV2Wpn7T/tOD+UfldjX/sP U3zP0250zwMk3K9YWu1lIDetQe47ppd4ykvy+G6je+9NtKk28e gLJRGJ/uLStdZVWh69M4S2Q8llN9A57fCOPTg0aM+LiMVNpXP7 zXymbRjVPaANKist6pW0Ry9X5LRD9sz+bFVunUhgvcxjhz/lAY dlGL+nQrlgKvpFrqRKNyhaRkGHHZfFMJ3Cn+c8WAhNE1iH0rlq AK+usrZD0YszjanM4n/TEbisOGWWRha7PXK9gHbV2QzBKgL5Qq rJRYDAFBZXeMtW4PDeSWbmXQOgb0riv4F3tvRTsSS+shqF2XNV vni9JPgf1wYAKlUzjKxFa7mWYlLfy3q+HvqmL7Tfx X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02/04/2012 04:49 PM, Jim Meyering wrote: > The above wasn't quite right in that it failed to honor mv's --backup > option. mv --backup s f would not have created the required backup file. > I've adjusted it to fix that, and added tests to cover both cases. > This is still not quite ready (i.e., the FIXME comment, where I'll add > some explanation), but otherwise should be fine. Thanks, looks fine. Have a nice day, Berny From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Bernhard Voelker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 07 Feb 2012 12:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Michael Felt Cc: 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.13286176363821 (code B ref 10686); Tue, 07 Feb 2012 12:28:01 +0000 Received: (at 10686) by debbugs.gnu.org; 7 Feb 2012 12:27:16 +0000 Received: from localhost ([127.0.0.1]:58425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ruk8h-0000zZ-Vj for submit@debbugs.gnu.org; Tue, 07 Feb 2012 07:27:16 -0500 Received: from moutng.kundenserver.de ([212.227.17.8]:61987) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ruk8f-0000zL-8Q for 10686@debbugs.gnu.org; Tue, 07 Feb 2012 07:27:14 -0500 Received: from [192.168.2.108] (p4FF77232.dip.t-dialin.net [79.247.114.50]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MBX2g-1RndNF03XS-00AjGC; Tue, 07 Feb 2012 13:26:11 +0100 Message-ID: <4F311861.1080707@bernhard-voelker.de> Date: Tue, 07 Feb 2012 13:26:09 +0100 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> <87fweqvbtd.fsf@rho.meyering.net> <4F2FE5F6.1010902@bernhard-voelker.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:V+T4nFQ11zjFaZ5ydaJVAfuDkot1+1vmIyB2Zc28uLX NKCDIEGet6CzIYnYt38vbTiFJFN1wN0khBNEUYs6RfE25nEyj3 b6DdwaqvW26QEPbOiQQNhc3rpfAWrwbGJGyDjTNAcThn9RT8K2 GlCai4dIpN9FpOZb+EkHyfqsP1rKks2cPiK5gvkJV4yhVCOym1 eW/MBKqk2oBxTfJebTsJrfGhB8fJ48xuvHWwy/HE/PM1a56Cj+ NL4sZtth9C5OnA21YdOx+PFgVlXKoLTI8apeCdDb1nCCQrSbXi 8/k4ySQU8jpExhiR7ZwPIvnXWNGCXchlixlT4ydc43xzXRhYry y6qjfneol+0Pq7klcTkLcu71c+OePSXhdLKrJp3fm X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02/07/2012 11:45 AM, Michael Felt wrote: > Just reading - for reference only - AIX 5.3, and I expect new versions behave as follows > (second link becomes a hardlink to original file, mv "removes" one hard link, i.e. original file (as inode) remains. > > root@x105:[/tmp/test]touch f > root@x105:[/tmp/test]ln -s f l > root@x105:[/tmp/test]ls -l > total 0 > -rw-r--r-- 1 root system 0 2012-02-07 11:41 f > lrwxrwxrwx 1 root system 1 2012-02-07 11:41 l -> f > root@x105:[/tmp/test]ln l s > root@x105:[/tmp/test]ls -ogi > total 0 > 239 -rw-r--r-- 2 0 2012-02-07 11:41 f > 240 lrwxrwxrwx 1 1 2012-02-07 11:41 l -> f > 239 -rw-r--r-- 2 0 2012-02-07 11:41 s > root@x105:[/tmp/test]mv s f > root@x105:[/tmp/test]ls -ogi > total 0 > 239 -rw-r--r-- 1 0 2012-02-07 11:41 f > 240 lrwxrwxrwx 1 1 2012-02-07 11:41 l -> f Hi Michael, the result is the same, but there's a little difference here: your ln does not create a hardlink to the symlink, but rather a hardlink to the symlink's *target*. On Linux, the situation before mv looks like this: $ touch f && ln -s f l && ln l s && ls -ogi total 0 11279 -rw-r--r-- 1 0 Feb 7 13:17 f 11280 lrwxrwxrwx 2 1 Feb 7 13:17 l -> f 11280 lrwxrwxrwx 2 1 Feb 7 13:17 s -> f Before Jim's patch, mv didn't remove the source, i.e. 's': $ /bin/mv s l ; ls -ogi total 0 11279 -rw-r--r-- 1 0 Feb 7 13:17 f 11280 lrwxrwxrwx 2 1 Feb 7 13:17 l -> f 11280 lrwxrwxrwx 2 1 Feb 7 13:17 s -> f Now, mv correctly unlinks 's': $ ~/git/coreutils/src/mv s l ; ls -ogi total 0 11279 -rw-r--r-- 1 0 Feb 7 13:17 f 11280 lrwxrwxrwx 1 1 Feb 7 13:17 l -> f Regarding your case, there's no change. Have a nice day, Berny From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 11 Feb 2012 11:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: Bernhard Voelker , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.13289595044980 (code B ref 10686); Sat, 11 Feb 2012 11:26:01 +0000 Received: (at 10686) by debbugs.gnu.org; 11 Feb 2012 11:25:04 +0000 Received: from localhost ([127.0.0.1]:35664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwB4f-0001I0-VT for submit@debbugs.gnu.org; Sat, 11 Feb 2012 06:25:02 -0500 Received: from mx.meyering.net ([88.168.87.75]:35468) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwB4c-0001Hb-4R for 10686@debbugs.gnu.org; Sat, 11 Feb 2012 06:25:00 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 38084601FB; Sat, 11 Feb 2012 12:23:38 +0100 (CET) From: Jim Meyering In-Reply-To: <87fweqvbtd.fsf@rho.meyering.net> (Jim Meyering's message of "Sat, 04 Feb 2012 16:49:02 +0100") References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> <87fweqvbtd.fsf@rho.meyering.net> Date: Sat, 11 Feb 2012 12:23:38 +0100 Message-ID: <8762fdbolh.fsf@rho.meyering.net> Lines: 172 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Jim Meyering wrote: > The above wasn't quite right in that it failed to honor mv's --backup > option. mv --backup s f would not have created the required backup file. > I've adjusted it to fix that, and added tests to cover both cases. > This is still not quite ready (i.e., the FIXME comment, where I'll add > some explanation), but otherwise should be fine. > > Date: Wed, 1 Feb 2012 21:42:45 +0100 > Subject: [PATCH] mv: "mv A B" would sometimes succeed, yet A would remain, > ... I address the FIXME and tweaked the comment: (A,B) seemed a little clearer than (s1,s2). I've also tightened up the test, regarding --backup and existence of backup files. >From de817cfa6e780323b3eac1f92ac81e8c7871d088 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 1 Feb 2012 21:42:45 +0100 Subject: [PATCH] mv: "mv A B" would sometimes succeed, yet A would remain, ... But only when both A and B were hard links to the same symlink. * src/copy.c (same_file_ok): Handle another special case: the one in which we are moving a symlink onto a hard link to itself. In this case, we must explicitly tell the caller to unlink the source file. Otherwise, at least the linux-3.x kernel rename function would do nothing, as mandated by POSIX 2008. * tests/mv/symlink-onto-hardlink-to-self: New test. * tests/Makefile.am (TESTS): Add it. * NEWS (Bug fixes): Mention it. Reported by Bernhard Voelker in http://bugs.gnu.org/10686 --- NEWS | 5 +++ src/copy.c | 29 +++++++++++++++-- tests/Makefile.am | 1 + tests/mv/symlink-onto-hardlink-to-self | 56 ++++++++++++++++++++++++++++++++ 4 files changed, 88 insertions(+), 3 deletions(-) create mode 100755 tests/mv/symlink-onto-hardlink-to-self diff --git a/NEWS b/NEWS index 9eebbf6..ca8c0b5 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,11 @@ GNU coreutils NEWS -*- outline -*- referent, there is no risk of data loss, since the symlink will typically still point to one of the hard links. + "mv A B" could succeed, yet A would remain. This would happen only when + both A and B were hard links to the same symlink, and with a kernel for + which rename("A","B") would do nothing and return 0. Now, in this + unusual case, mv does not call rename, and instead simply unlinks A. + * Noteworthy changes in release 8.15 (2012-01-06) [stable] diff --git a/src/copy.c b/src/copy.c index 4810de8..541ca20 100644 --- a/src/copy.c +++ b/src/copy.c @@ -1226,10 +1226,33 @@ same_file_ok (char const *src_name, struct stat const *src_sb, same_link = same; /* If both the source and destination files are symlinks (and we'll - know this here IFF preserving symlinks), then it's ok -- as long - as they are distinct. */ + know this here IFF preserving symlinks), then it's usually ok + when they are distinct. */ if (S_ISLNK (src_sb->st_mode) && S_ISLNK (dst_sb->st_mode)) - return ! same_name (src_name, dst_name); + { + bool sn = same_name (src_name, dst_name); + if ( ! sn) + { + /* It's fine when we're making any type of backup. */ + if (x->backup_type != no_backups) + return true; + + /* Here we have two symlinks that are hard-linked together, + and we're not making backups. In this unusual case, simply + returning true would lead to mv calling "rename(A,B)", + which would do nothing and return 0. I.e., A would + not be removed. Hence, the solution is to tell the + caller that all it must do is unlink A and return. */ + if (same_link) + { + *unlink_src = true; + *return_now = true; + return true; + } + } + + return ! sn; + } src_sb_link = src_sb; dst_sb_link = dst_sb; diff --git a/tests/Makefile.am b/tests/Makefile.am index a94aaa2..c951f69 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -492,6 +492,7 @@ TESTS = \ mv/partition-perm \ mv/perm-1 \ mv/symlink-onto-hardlink \ + mv/symlink-onto-hardlink-to-self \ mv/to-symlink \ mv/trailing-slash \ mv/update \ diff --git a/tests/mv/symlink-onto-hardlink-to-self b/tests/mv/symlink-onto-hardlink-to-self new file mode 100755 index 0000000..efaff66 --- /dev/null +++ b/tests/mv/symlink-onto-hardlink-to-self @@ -0,0 +1,56 @@ +#!/bin/sh +# Demonstrate that when moving a symlink onto a hardlink-to-that-symlink, the +# source symlink is removed. Depending on your kernel (e.g., with the linux +# kernel), prior to coreutils-8.16, the mv would successfully perform a no-op. +# I.e., surprisingly, mv s1 s2 would succeed, yet fail to remove s1. + +# Copyright (C) 2012 Free Software Foundation, Inc. + +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +. "${srcdir=.}/init.sh"; path_prepend_ ../src +print_ver_ mv + +# Create a file f, and a symlink s1 to that file. +touch f || framework_failure_ +ln -s f s2 || framework_failure_ + +for opt in '' --backup; do + + # Attempt to create a hard link to that symlink. + # On some systems, it's not possible: they create a hard link to the referent. + ln s2 s1 || framework_failure_ + + # If s1 is not a symlink, skip this test. + test -h s1 \ + || skip_ your kernel or file system cannot create a hard link to a symlink + + mv $opt s1 s2 > out 2>&1 || fail=1 + compare /dev/null out || fail=1 + + # Ensure that s1 is gone. + test -e s1 && fail=1 + + if test "$opt" = --backup; then + # With --backup, ensure that the backup file was created. + ref=$(readlink s2~) || fail=1 + test "$ref" = f || fail=1 + else + # Without --backup, ensure there is no backup file. + test -e s2~ && fail=1 + fi + +done + +Exit $fail -- 1.7.9.190.gf1d33 From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 11 Feb 2012 12:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: Bernhard Voelker , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132896429215212 (code B ref 10686); Sat, 11 Feb 2012 12:45:01 +0000 Received: (at 10686) by debbugs.gnu.org; 11 Feb 2012 12:44:52 +0000 Received: from localhost ([127.0.0.1]:35771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwCJw-0003xJ-8c for submit@debbugs.gnu.org; Sat, 11 Feb 2012 07:44:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61997) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwCJp-0003wz-OT for 10686@debbugs.gnu.org; Sat, 11 Feb 2012 07:44:51 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1BChHDS000931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Feb 2012 07:43:17 -0500 Received: from [10.3.113.115] (ovpn-113-115.phx2.redhat.com [10.3.113.115]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1BChGTY030525; Sat, 11 Feb 2012 07:43:16 -0500 Message-ID: <4F366263.1000200@redhat.com> Date: Sat, 11 Feb 2012 05:43:15 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> <87fweqvbtd.fsf@rho.meyering.net> <8762fdbolh.fsf@rho.meyering.net> In-Reply-To: <8762fdbolh.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig37D1A274112BD83C711726B9" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig37D1A274112BD83C711726B9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/11/2012 04:23 AM, Jim Meyering wrote: > +++ b/NEWS > @@ -11,6 +11,11 @@ GNU coreutils NEWS = -*- outline -*- > referent, there is no risk of data loss, since the symlink will > typically still point to one of the hard links. >=20 > + "mv A B" could succeed, yet A would remain. This would happen only = when > + both A and B were hard links to the same symlink, and with a kernel = for > + which rename("A","B") would do nothing and return 0. Now, in this > + unusual case, mv does not call rename, and instead simply unlinks A.= You make it sound like a kernel where rename("A","B") returns 0 is unusual; on the contrary, that is normal, since it is the POSIX-mandated behavior for kernels. What is unusual is having two hardlinks to the same symlink. Maybe we should reword this slightly, to attach the "unusual" modifier to the correct phrase, or even take "kernel" out of the description: "mv A B" could succeed, yet A would remain. This would only happen in the unusual case when both A and B were hard links to the same symlink, due to the standard behavior of rename. Now, mv recognizes the case and simply unlinks A. > +++ b/tests/mv/symlink-onto-hardlink-to-self > @@ -0,0 +1,56 @@ > +#!/bin/sh > +# Demonstrate that when moving a symlink onto a hardlink-to-that-symli= nk, the > +# source symlink is removed. Depending on your kernel (e.g., with the= linux > +# kernel), prior to coreutils-8.16, the mv would successfully perform = a no-op. Again, this is the POSIX-required behavior of ALL kernels, and not something special to Linux. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig37D1A274112BD83C711726B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPNmJkAAoJEKeha0olJ0NqYOYH/3Q2serbTYNCCbmsNwPA7H2V VSsAtd5C00lp4XZOXGWlHoCnRzI8LjzvYYMdLSqlDO0GZQi7yfX2ZDB84nErMv+m Sn03xjNUP6FaIIBYhYl5PWEeswWjxc2PHN2BkFvLt3bPAs86xFB+F99WfrhHt9ga jUwtRPkY9TbjCNt/Bpo5Z7kIOimAomtETfjz1Sb8j7idc1yGWuFjdNVo5qQBKGSh ees7zjCOUjM4NzI8ix1O2BOSrkuZDG7im9T/3IBVttlQNX2z7Dp8cQsDGADHOsO0 FtJ8EzmKdgYNSC7V8ripAhw1sOAB2x3yI3+QUmY8nmVicf86ISIDPdpT4UPy8ks= =mgo9 -----END PGP SIGNATURE----- --------------enig37D1A274112BD83C711726B9-- From unknown Sat Aug 09 15:55:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10686: mv: moving hardlink of a softlink to the softlink does nothing Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sun, 12 Feb 2012 13:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10686 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: Bernhard Voelker , 10686@debbugs.gnu.org Received: via spool by 10686-submit@debbugs.gnu.org id=B10686.132905256915319 (code B ref 10686); Sun, 12 Feb 2012 13:17:02 +0000 Received: (at 10686) by debbugs.gnu.org; 12 Feb 2012 13:16:09 +0000 Received: from localhost ([127.0.0.1]:36851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwZHk-0003z1-T1 for submit@debbugs.gnu.org; Sun, 12 Feb 2012 08:16:09 -0500 Received: from mx.meyering.net ([88.168.87.75]:38961) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwZHi-0003ys-55 for 10686@debbugs.gnu.org; Sun, 12 Feb 2012 08:16:07 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 2AA9460062; Sun, 12 Feb 2012 14:14:40 +0100 (CET) From: Jim Meyering In-Reply-To: <4F366263.1000200@redhat.com> (Eric Blake's message of "Sat, 11 Feb 2012 05:43:15 -0700") References: <4F28F5F5.4030306@bernhard-voelker.de> <87mx92en4f.fsf@rho.meyering.net> <4F2953B1.4000903@redhat.com> <87wr86blrx.fsf@rho.meyering.net> <87fweqvbtd.fsf@rho.meyering.net> <8762fdbolh.fsf@rho.meyering.net> <4F366263.1000200@redhat.com> Date: Sun, 12 Feb 2012 14:14:40 +0100 Message-ID: <8762fc9osf.fsf@rho.meyering.net> Lines: 68 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eric Blake wrote: > On 02/11/2012 04:23 AM, Jim Meyering wrote: >> +++ b/NEWS ... >> + "mv A B" could succeed, yet A would remain. This would happen only when >> + both A and B were hard links to the same symlink, and with a kernel for >> + which rename("A","B") would do nothing and return 0. Now, in this >> + unusual case, mv does not call rename, and instead simply unlinks A. > > You make it sound like a kernel where rename("A","B") returns 0 is > unusual; Thank you for the review and suggestions. Such kernels *should* be unusual. This rename-is-sometimes-a-no-op exception makes it hard to use rename in an application that must reliably produce results that make sense even to people who don't care what inodes and invariants are. > on the contrary, that is normal, since it is the POSIX-mandated > behavior for kernels. What is unusual is having two hardlinks to the > same symlink. Maybe we should reword this slightly, to attach the > "unusual" modifier to the correct phrase, or even take "kernel" out of > the description: > > "mv A B" could succeed, yet A would remain. This would only happen > in the unusual case when both A and B were hard links to the same > symlink, due to the standard behavior of rename. Now, mv recognizes > the case and simply unlinks A. This is the NEWS file, where we prefer to stick to the facts, but I feel I have to make a small statement, so have adjusted it like this: "mv A B" could succeed, yet A would remain. This would happen only when both A and B were hard links to the same symlink, and with a kernel for which rename("A","B") does nothing and returns 0 (POSIX mandates this surprising rename no-op behavior). Now, mv handles this case by skipping the usually-useless rename and simply unlinking A. >> +++ b/tests/mv/symlink-onto-hardlink-to-self >> @@ -0,0 +1,56 @@ >> +#!/bin/sh >> +# Demonstrate that when moving a symlink onto a hardlink-to-that-symlink, the >> +# source symlink is removed. Depending on your kernel (e.g., with the linux >> +# kernel), prior to coreutils-8.16, the mv would successfully perform a no-op. > > Again, this is the POSIX-required behavior of ALL kernels, and not > something special to Linux. NetBSD 5.1 has the sensible kernel rename behavior, i.e., what one would expect in the absence of standardized legacy: netbsd$ : > f; ln f g; perl -e 'rename qw(f g) or die "$!"'; ls f g ls: cannot access f: No such file or directory g [Exit 2] Programs like mv should not have to jump through hoops like copy.c's same_file_ok function just to avoid the surprising (nonsensical, to most) behavior of the standardized rename syscall. I adjusted that comment, too, and pushed the result: # Demonstrate that when moving a symlink onto a hardlink-to-that-symlink, the # source symlink is removed. Depending on your kernel (e.g., Linux, Solaris, # but not NetBSD), prior to coreutils-8.16, the mv would successfully perform # a no-op. I.e., surprisingly, mv s1 s2 would succeed, yet fail to remove s1. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 16 12:20:12 2018 Received: (at control) by debbugs.gnu.org; 16 Oct 2018 16:20:12 +0000 Received: from localhost ([127.0.0.1]:53850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCS4q-00013x-AU for submit@debbugs.gnu.org; Tue, 16 Oct 2018 12:20:12 -0400 Received: from mail-pl1-f172.google.com ([209.85.214.172]:34512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCS4m-00013Q-KV for control@debbugs.gnu.org; Tue, 16 Oct 2018 12:20:08 -0400 Received: by mail-pl1-f172.google.com with SMTP id f18-v6so11265192plr.1 for ; Tue, 16 Oct 2018 09:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:message-id:date:user-agent:mime-version:content-language :content-transfer-encoding; bh=AqczNDh/vp2NGBYgsZf9o2y/Vrx8zdz3ALsEcqB8lGc=; b=Jh7vBPIT3Zu+obEv6PbvBbuktKD5I66lagqYFLOIsgGyq/dB13N75stazAHxgewMfJ vF/XZkLVFbrg4i+h9BqZ+tEwpc3/+1ONY/CBVtVxZ7XvedYmYLBV/s3fmlrhNlhoaAHm kY4lbmGoosyLLRrud2JTy0JcRparrcrXfqTGRNDbRFX9MVW252AIsr8X85ssYL8C0JEp rNou4edmIPNVAowPg3TRa7tVMaDD2kWVBZ4wJh48zMjJFmXtw9lW9+4neGFR6cnKbOn6 3agLhEuQp+M2ZeZLECaKm6aewK64OEqYpoUPWJe6YC9yxGSiL+6FWft9h4Y2AvVifzvJ Cn6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=AqczNDh/vp2NGBYgsZf9o2y/Vrx8zdz3ALsEcqB8lGc=; b=AONYaS+rB8V215dgNA0TXRmOPuJC+UjqZ9tTa4O25JMiLWU5rNLVLC6jHwf4FXpI4N 536xvX1kR4QLnlZ4NYnsad4P7L+N5OpilbtOmz+UVS0ffmx7f93adE91KzyEEB6IcYc4 hIgIJsgIO9gEYtQNWfP5EM1OukGgdx1vyg5MdCDralQzSipt9m24cx2Pgq2V8crdh+mK o5l3c8/YLvjcZjzgEzl5ONxksXHMb0fIcaY4WrsLaRoZmNz4wK7J9+grqy79WLIyYLFU GJuEvkWcwxuP9yIT0FSMW2g7RxJOhv972z1+rNO7+RvVzEfOmRg16s4GGzQmQAlu7/Mw km3g== X-Gm-Message-State: ABuFfojaAT4taRK5ahhzucUe4xxJsSHmdey0cOmjqA48UuPcyKs2G3Gq iHnRmjeW6u9VXHLJsL2PgiBAYDne0kg= X-Google-Smtp-Source: ACcGV61uUHbrA1UpLo4d/wJuipcI8b4C4xl+OJ4TrNjDU+AmiGU09tdHsUbjCVRLxEL2hZwlQadNxA== X-Received: by 2002:a17:902:43a4:: with SMTP id j33-v6mr10605695pld.131.1539706802497; Tue, 16 Oct 2018 09:20:02 -0700 (PDT) Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38]) by smtp.googlemail.com with ESMTPSA id x17-v6sm16540897pfn.59.2018.10.16.09.20.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 09:20:01 -0700 (PDT) To: control@debbugs.gnu.org From: Assaf Gordon Message-ID: <0058a8fb-e907-9fbe-c3b4-0a87682ece0a@gmail.com> Date: Tue, 16 Oct 2018 10:20:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 10679 wishlist tags 10686 fixed close 10686 severity 10755 wishlist retitle 10755 stat: Please add directive to display size on disk (%S) [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (assafgordon[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.214.172 listed in list.dnswl.org] 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) severity 10679 wishlist tags 10686 fixed close 10686 severity 10755 wishlist retitle 10755 stat: Please add directive to display size on disk (%S)