From unknown Thu Sep 11 02:24:01 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#6960 <6960@debbugs.gnu.org> To: bug#6960 <6960@debbugs.gnu.org> Subject: Status: mv refuses to move a symlink over a hard link to the same file Reply-To: bug#6960 <6960@debbugs.gnu.org> Date: Thu, 11 Sep 2025 09:24:01 +0000 retitle 6960 mv refuses to move a symlink over a hard link to the same file reassign 6960 coreutils submitter 6960 Matt McCutchen severity 6960 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 31 17:26:59 2010 Received: (at submit) by debbugs.gnu.org; 31 Aug 2010 21:26:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqYM6-0002rx-6m for submit@debbugs.gnu.org; Tue, 31 Aug 2010 17:26:58 -0400 Received: from mx10.gnu.org ([199.232.76.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqYJB-0002pz-9A for submit@debbugs.gnu.org; Tue, 31 Aug 2010 17:23:58 -0400 Received: from lists.gnu.org ([199.232.76.165]:50389) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OqYKl-0007K6-WE for submit@debbugs.gnu.org; Tue, 31 Aug 2010 17:25:36 -0400 Received: from [140.186.70.92] (port=59688 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqYKg-0006yX-1a for bug-coreutils@gnu.org; Tue, 31 Aug 2010 17:25:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqYGW-0001dv-Ru for bug-coreutils@gnu.org; Tue, 31 Aug 2010 17:21:14 -0400 Received: from caiajhbdcbhh.dreamhost.com ([208.97.132.177]:46586 helo=homiemail-a37.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqYGW-0001d8-Nw for bug-coreutils@gnu.org; Tue, 31 Aug 2010 17:21:12 -0400 Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id A4CD51D006D for ; Tue, 31 Aug 2010 14:21:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=IY7qt+d 9UF+UE4jLEOUsPvFy4+d0A+ddkEneKgrdkDRzuvx1019iQ5TU2e5eSU6heVNajEN atIdKdjobJujwB8tS/cKYMOAKxEVFo/eyH8Uiu97ATwqC1z4kS+o/tqXkevrCzEb I8c9jRDkDcG9Q9yZv0YrbK1qR+QBt8bHzNuM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=8jW+aQw1c4y+z S2HpilXjwSZnMA=; b=jme1ZLl4IcBmOB+HUuh/ZLqagA73PnZMwf8X/GE+3SpjE /99f/NYlnsAjKle6sGMNT6+Bt5R8VotWLSXXQB/T7rzRCAK8mzkFBU3k8f0vqhwi qm3Cr/bQy9uAqnfTeo/pT46V1PLb5OSxf2GqPl3DJhpF7+QAWlC6qOLmXz+ps0= Received: from [129.2.139.11] (129-2-139-11.wireless.umd.edu [129.2.139.11]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 6C5F21D0069 for ; Tue, 31 Aug 2010 14:21:10 -0700 (PDT) Subject: mv refuses to move a symlink over a hard link to the same file From: Matt McCutchen To: bug-coreutils@gnu.org Content-Type: text/plain; charset="UTF-8" Date: Tue, 31 Aug 2010 17:21:08 -0400 Message-ID: <1283289668.1923.79.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Tue, 31 Aug 2010 17:26:57 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -5.4 (-----) If mv is asked to move a symlink over a hard link to the same file, it fails with the message, "A and B are the same file". There is no reason why it should complain rather than perform the move. Example: $ ~/coreutils/coreutils.usr/bin/mv --version mv (GNU coreutils) 8.5.143-77702 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Mike Parker, David MacKenzie, and Jim Meyering. $ touch New_York $ ln New_York localtime $ ln -s New_York localtime.new $ ls -l total 0 -rw------- 2 matt matt 0 2010-08-31 17:10 New_York -rw------- 2 matt matt 0 2010-08-31 17:10 localtime lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York $ ~/coreutils/coreutils.usr/bin/mv localtime.new localtime /home/matt/coreutils/coreutils.usr/bin/mv: `localtime.new' and `localtime' are the same file -- Matt From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 31 19:01:37 2010 Received: (at submit) by debbugs.gnu.org; 31 Aug 2010 23:01:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqZpf-0004Eb-F7 for submit@debbugs.gnu.org; Tue, 31 Aug 2010 19:01:35 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqZpd-0004ET-Ns for submit@debbugs.gnu.org; Tue, 31 Aug 2010 19:01:34 -0400 Received: from lists.gnu.org ([199.232.76.165]:55784) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OqZrE-0007mm-OK for submit@debbugs.gnu.org; Tue, 31 Aug 2010 19:03:12 -0400 Received: from [140.186.70.92] (port=37570 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqZr9-0003rc-FM for bug-coreutils@gnu.org; Tue, 31 Aug 2010 19:03:12 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqZr4-0000ij-BF for bug-coreutils@gnu.org; Tue, 31 Aug 2010 19:03:07 -0400 Received: from mailout-eu.gmx.com ([213.165.64.42]:40909) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OqZr3-0000iQ-Tb for bug-coreutils@gnu.org; Tue, 31 Aug 2010 19:03:02 -0400 Received: (qmail invoked by alias); 31 Aug 2010 23:02:59 -0000 Received: from hex.aaisp.net.uk (EHLO scooter.muppet.show) [90.155.53.9] by mail.gmx.com (mp-eu003) with SMTP; 01 Sep 2010 01:02:59 +0200 X-Authenticated: #48875277 X-Provags-ID: V01U2FsdGVkX19PYMI5noZP4PUZNTxuGDmoWAB88yPRJEL2ognlKy ht279cZDEID3d6 Date: Tue, 31 Aug 2010 23:48:56 +0100 From: Davide Brini To: bug-coreutils@gnu.org Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file Message-ID: <20100831234856.6292c158@scooter.muppet.show> In-Reply-To: <1283289668.1923.79.camel@mattlaptop2.local> References: <1283289668.1923.79.camel@mattlaptop2.local> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -5.6 (-----) On Tue, 31 Aug 2010 17:21:08 -0400 Matt McCutchen wrote: > If mv is asked to move a symlink over a hard link to the same file, it > fails with the message, "A and B are the same file". There is no reason > why it should complain rather than perform the move. Example: > > $ ~/coreutils/coreutils.usr/bin/mv --version > mv (GNU coreutils) 8.5.143-77702 > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > . This is free software: you are free > to change and redistribute it. There is NO WARRANTY, to the extent > permitted by law. > > Written by Mike Parker, David MacKenzie, and Jim Meyering. > $ touch New_York > $ ln New_York localtime > $ ln -s New_York localtime.new > $ ls -l > total 0 > -rw------- 2 matt matt 0 2010-08-31 17:10 New_York > -rw------- 2 matt matt 0 2010-08-31 17:10 localtime > lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York > $ ~/coreutils/coreutils.usr/bin/mv localtime.new localtime > /home/matt/coreutils/coreutils.usr/bin/mv: `localtime.new' and > `localtime' are the same file A simpler example is something like $ touch New_York $ ln -s New_York New_York.sym $ mv New_York.sym New_York mv: `New_York.sym' and `New_York' are the same file I think the reason is that when the source is a symbolic link, mv operates on the symlink itself, not the file it points to. So, it can't rename the symlink, because if successful that would imply having two entries named "New_York" in the same directory. If this is really the reason for the error, the error message could probably be improved. -- D. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 31 19:29:02 2010 Received: (at submit) by debbugs.gnu.org; 31 Aug 2010 23:29:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqaGE-0004OA-3g for submit@debbugs.gnu.org; Tue, 31 Aug 2010 19:29:02 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqaGB-0004O3-2D for submit@debbugs.gnu.org; Tue, 31 Aug 2010 19:29:00 -0400 Received: from lists.gnu.org ([199.232.76.165]:58650) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OqaHm-0007xx-4f for submit@debbugs.gnu.org; Tue, 31 Aug 2010 19:30:38 -0400 Received: from [140.186.70.92] (port=57306 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqaHg-0000ti-Ps for bug-coreutils@gnu.org; Tue, 31 Aug 2010 19:30:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqaHX-0004Y9-S5 for bug-coreutils@gnu.org; Tue, 31 Aug 2010 19:30:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31145) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqaHX-0004Y2-M4 for bug-coreutils@gnu.org; Tue, 31 Aug 2010 19:30:23 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7VNUKRW003686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Aug 2010 19:30:20 -0400 Received: from [10.3.113.60] (ovpn-113-60.phx2.redhat.com [10.3.113.60]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7VNUJEQ031305; Tue, 31 Aug 2010 19:30:20 -0400 Message-ID: <4C7D908B.5010104@redhat.com> Date: Tue, 31 Aug 2010 17:30:19 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2 MIME-Version: 1.0 To: Davide Brini Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file References: <1283289668.1923.79.camel@mattlaptop2.local> <20100831234856.6292c158@scooter.muppet.show> In-Reply-To: <20100831234856.6292c158@scooter.muppet.show> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: submit Cc: bug-coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -7.7 (-------) On 08/31/2010 04:48 PM, Davide Brini wrote: > A simpler example is something like > > $ touch New_York > $ ln -s New_York New_York.sym > $ mv New_York.sym New_York > mv: `New_York.sym' and `New_York' are the same file > > I think the reason is that when the source is a symbolic link, mv operates > on the symlink itself, not the file it points to. So, it can't rename the > symlink, because if successful that would imply having two entries named > "New_York" in the same directory. Not quite. POSIX specifies that: http://www.opengroup.org/onlinepubs/9699919799/utilities/mv.html If the source_file operand and destination path name the same existing file, then the destination path shall not be removed, and one of the following shall occur: 1. No change is made to source_file, no error occurs, and no diagnostic is issued. 2. No change is made to source_file, a diagnostic is issued to standard error identifying the two names, and the exit status is affected. 3. 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 question boils down to whether "New_York" and "New_York.sym" name the same file (stat semantics), or whether, since mv generally operates on symlinks rather than dereferencing them, they are distinct files (lstat semantics). Solaris /usr/xpg4/bin/mv (which is supposedly POSIX-compliant, although we could debate that) goes ahead with the move: $ touch a $ ln -s a b $ /usr/xpg4/bin/mv b a $ echo $? ? 0 a $ readlink a a Certainly, the underlying rename() call is allowed to replace a file with a symlink, even if the symlink was to the file that it was replacing (and thus will create an ELOOP situation on the symlink while losing the contents that were pointed to). So, in that regards, you could argue that Solaris' behavior is dangerous (it lost data) while coreutils is playing it safe, when the destination has a link count of 1 in this simplified example. But when the destination has a link count of 2, there is no data loss, so the original example seems like it is pointing out a case where coreutils is over-strict. And I would argue that the strict POSIX wording says that we should only be refusing to move if the two files have the same inode; in both the original and simplified examples, the symlink has a different inode than the file it would be overwriting, so I think POSIX mandates that the data destruction happen rather than the coreutils behavior. Maybe this would argue for a POSIXLY_CORRECT behavior choice? :( Maybe we need to raise this as a question to the Austin Group to argue that coreutils behavior should be permitted? > If this is really the reason for the > error, the error message could probably be improved. This part is true - the error message could definitely be more precise, if we decide that POSIX even lets us issue an error in the first place. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 31 20:03:12 2010 Received: (at submit) by debbugs.gnu.org; 1 Sep 2010 00:03:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqanG-0004b2-JN for submit@debbugs.gnu.org; Tue, 31 Aug 2010 20:03:11 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqanE-0004ax-EX for submit@debbugs.gnu.org; Tue, 31 Aug 2010 20:03:09 -0400 Received: from lists.gnu.org ([199.232.76.165]:58425) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Oqaop-000835-BV for submit@debbugs.gnu.org; Tue, 31 Aug 2010 20:04:47 -0400 Received: from [140.186.70.92] (port=51130 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oqaon-0007eu-UE for bug-coreutils@gnu.org; Tue, 31 Aug 2010 20:04:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oqaom-0000Fu-FT for bug-coreutils@gnu.org; Tue, 31 Aug 2010 20:04:45 -0400 Received: from mailout-eu.gmx.com ([213.165.64.42]:39809) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Oqaom-0000FY-0U for bug-coreutils@gnu.org; Tue, 31 Aug 2010 20:04:44 -0400 Received: (qmail invoked by alias); 01 Sep 2010 00:04:41 -0000 Received: from hex.aaisp.net.uk (EHLO scooter.muppet.show) [90.155.53.9] by mail.gmx.com (mp-eu003) with SMTP; 01 Sep 2010 02:04:41 +0200 X-Authenticated: #48875277 X-Provags-ID: V01U2FsdGVkX1+W9u9UDGiW+mPx3KhgXiKgFU3uktP0LfXnjM54gK 3svuJp43YoA4Pe Date: Wed, 1 Sep 2010 00:50:38 +0100 From: Davide Brini To: Eric Blake Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file Message-ID: <20100901005038.6e4de0d6@scooter.muppet.show> In-Reply-To: <4C7D908B.5010104@redhat.com> References: <1283289668.1923.79.camel@mattlaptop2.local> <20100831234856.6292c158@scooter.muppet.show> <4C7D908B.5010104@redhat.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: submit Cc: bug-coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -5.6 (-----) On Tue, 31 Aug 2010 17:30:19 -0600 Eric Blake wrote: > Not quite. POSIX specifies that: > http://www.opengroup.org/onlinepubs/9699919799/utilities/mv.html > > If the source_file operand and destination path name the same existing > file, then the destination path shall not be removed, and one of the > following shall occur: > > 1. No change is made to source_file, no error occurs, and no > diagnostic is issued. > 2. No change is made to source_file, a diagnostic is issued to > standard error identifying the two names, and the exit status is affected. > 3. 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 question boils down to whether "New_York" and "New_York.sym" name > the same file (stat semantics), or whether, since mv generally operates > on symlinks rather than dereferencing them, they are distinct files > (lstat semantics). > > Solaris /usr/xpg4/bin/mv (which is supposedly POSIX-compliant, although > we could debate that) goes ahead with the move: > $ touch a > $ ln -s a b > $ /usr/xpg4/bin/mv b a > $ echo $? ? > 0 a > $ readlink a > a So they are saying that, since "a" and "b" do not "name the same existing file", this has to be a perfectly normal rename, although this causes loss of data. (but then, if one does "mv a b" and "a" and "b" are two different regular files, there also is a loss of data because the contents of "b" are overwritten, so from that point of view our example isn't special) > Certainly, the underlying rename() call is allowed to replace a file > with a symlink Thanks, this was actually my doubt (although now I recognize it wasn't at all apparent from my previous message). > even if the symlink was to the file that it was > replacing (and thus will create an ELOOP situation on the symlink while > losing the contents that were pointed to). Creating ELOOP is already possible (eg "ln -s a a", although this does not cause any loss of data). > So, in that regards, you > could argue that Solaris' behavior is dangerous (it lost data) while > coreutils is playing it safe, when the destination has a link count of 1 > in this simplified example. But when the destination has a link count > of 2, there is no data loss, so the original example seems like it is > pointing out a case where coreutils is over-strict. > > And I would argue that the strict POSIX wording says that we should only > be refusing to move if the two files have the same inode; in both the > original and simplified examples, the symlink has a different inode than > the file it would be overwriting, so I think POSIX mandates that the > data destruction happen rather than the coreutils behavior. Given that rename() can replace a file with a symlink, I would say so, but I have no authority on the subject :) > Maybe this would argue for a POSIXLY_CORRECT behavior choice? :( > > Maybe we need to raise this as a question to the Austin Group to argue > that coreutils behavior should be permitted? This sounds like a good idea. Perhaps first get the interpretation of the standard clarified, and if it turns out to be the destructive one as it would seem, either always behave that way, or only when POSIXLY_CORRECT. If instead the current coreutils behavior is already allowed by POSIX, all the better. -- D. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 02 04:06:10 2010 Received: (at 6960) by debbugs.gnu.org; 2 Sep 2010 08:06:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or4oE-0000gS-LY for submit@debbugs.gnu.org; Thu, 02 Sep 2010 04:06:10 -0400 Received: from smtp1-g21.free.fr ([212.27.42.1]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or4oB-0000g6-UJ for 6960@debbugs.gnu.org; Thu, 02 Sep 2010 04:06:09 -0400 Received: from mx.meyering.net (unknown [82.230.74.64]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9ACCE940034 for <6960@debbugs.gnu.org>; Thu, 2 Sep 2010 10:07:45 +0200 (CEST) Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id 45109E277; Thu, 2 Sep 2010 10:07:44 +0200 (CEST) From: Jim Meyering To: Matt McCutchen Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <1283289668.1923.79.camel@mattlaptop2.local> (Matt McCutchen's message of "Tue, 31 Aug 2010 17:21:08 -0400") References: <1283289668.1923.79.camel@mattlaptop2.local> Date: Thu, 02 Sep 2010 10:07:44 +0200 Message-ID: <87sk1sin5b.fsf@meyering.net> Lines: 53 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -3.3 (---) Matt McCutchen wrote: > If mv is asked to move a symlink over a hard link to the same file, it > fails with the message, "A and B are the same file". There is no reason > why it should complain rather than perform the move. Actually, there is a very good reason. See below. > Example: ... > $ touch New_York > $ ln New_York localtime > $ ln -s New_York localtime.new > $ ls -l > total 0 > -rw------- 2 matt matt 0 2010-08-31 17:10 New_York > -rw------- 2 matt matt 0 2010-08-31 17:10 localtime > lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York > $ ~/coreutils/coreutils.usr/bin/mv localtime.new localtime > /home/matt/coreutils/coreutils.usr/bin/mv: `localtime.new' and `localtime' are the same file Here, your regular file, New_York, happens to be empty. That is a special, degenerate case. If you lose this file, via use of mv, you lose nothing at all. Well, in general, you might lose convenient access to the destination inode, if it had two or more links. But what if it contained a copy of some important document? It is a problem of perception. The user sees two files, A and B. The naive user sees that they have the same contents, but does not notice they are symlinked. May not even know what a symlink is... Our user decides to get rid of the duplicate. The lucky naive user moves the real file onto the symlink (say "mv A B") and that succeeds. If however, s/he uses the other argument ordering ("mv B A") and moves the symlink onto the real file, some versions of "mv" would leave our poor user with no copy of the original file. This is called "data loss" ;-) The user did nothing wrong, yet ended up destroying what may have been important data. That is why GNU mv deliberately refuses to perform the offending operation. One may argue that there is no data loss when the destination link count is 2 or more, but once the destination has been unlinked, it may be very challenging to locate another copy. This is not a bug in GNU mv. It is a deliberate feature. Personally, I prefer the semantics of 'mv -f --backup=numbered' so use a shell alias. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 02 06:08:23 2010 Received: (at 6960) by debbugs.gnu.org; 2 Sep 2010 10:08:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or6iU-0001Ua-UL for submit@debbugs.gnu.org; Thu, 02 Sep 2010 06:08:23 -0400 Received: from m0019.fra.mmp.de.bt.com ([62.180.227.30] helo=ms04.m0019.fra.mmp.de.bt.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or6iT-0001UU-8Z for 6960@debbugs.gnu.org; Thu, 02 Sep 2010 06:08:22 -0400 Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1368742; Thu, 2 Sep 2010 12:10:02 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 426F61EB82AB; Thu, 2 Sep 2010 12:10:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 2 Sep 2010 12:10:02 +0200 From: "Voelker, Bernhard" To: Jim Meyering , Matt McCutchen Date: Thu, 2 Sep 2010 12:10:01 +0200 Subject: RE: bug#6960: mv refuses to move a symlink over a hard link to the same file Thread-Topic: bug#6960: mv refuses to move a symlink over a hard link to the same file Thread-Index: ActKd6zB9hRx3mOGToq+QYcg8x3DpAADMA3w Message-ID: <7856072A9D04C24B82DFE2B1112FE38A0177BE57A0@MCHP058A.global-ad.net> References: <1283289668.1923.79.camel@mattlaptop2.local> <87sk1sin5b.fsf@meyering.net> In-Reply-To: <87sk1sin5b.fsf@meyering.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 6960 Cc: "6960@debbugs.gnu.org" <6960@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -2.5 (--) Jim Meyering wrote: > It is a deliberate feature. > > Personally, I prefer the semantics of 'mv -f --backup=3Dnumbered' > so use a shell alias. just for fun I tried to get no backup created and tried '--backup=3Dnever', but a backup is still created (version 8.5 on Cygwin, and 5.93 on SLES-10.3= ): $ uname -a > a $ ln -s a b $ mv -v --backup=3Dnever b a `b' -> `a' (backup: `a~') $ ls -l a a~ lrwxrwxrwx 1 vb027591 ugrp 1 2010-09-02 11:50 a -> a -rw-r--r--+ 1 vb027591 ugrp 69 2010-09-02 11:50 a~ I expected mv either to fail as if --backup=3D... is not given, or that it moves the file without creating a backup. Maybe I'm a bit confused that the combination of the words "backup" and "never" contrasts to what it does: it _creates_ a backup - though mentioned in manual: $ man mv ... simple, never always make simple backups Am I just misunderstanding the backup CONTROL "never"? Have a nice day, Berny= From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 02 06:26:46 2010 Received: (at 6960) by debbugs.gnu.org; 2 Sep 2010 10:26:46 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or70H-0001dJ-R2 for submit@debbugs.gnu.org; Thu, 02 Sep 2010 06:26:46 -0400 Received: from smtp1-g21.free.fr ([212.27.42.1]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or70D-0001dC-RH for 6960@debbugs.gnu.org; Thu, 02 Sep 2010 06:26:43 -0400 Received: from mx.meyering.net (unknown [82.230.74.64]) by smtp1-g21.free.fr (Postfix) with ESMTP id CC2AB940049 for <6960@debbugs.gnu.org>; Thu, 2 Sep 2010 12:28:19 +0200 (CEST) Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id 72DCCDB32; Thu, 2 Sep 2010 12:28:18 +0200 (CEST) From: Jim Meyering To: "Voelker\, Bernhard" Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <7856072A9D04C24B82DFE2B1112FE38A0177BE57A0@MCHP058A.global-ad.net> (Bernhard Voelker's message of "Thu, 2 Sep 2010 12:10:01 +0200") References: <1283289668.1923.79.camel@mattlaptop2.local> <87sk1sin5b.fsf@meyering.net> <7856072A9D04C24B82DFE2B1112FE38A0177BE57A0@MCHP058A.global-ad.net> Date: Thu, 02 Sep 2010 12:28:18 +0200 Message-ID: <87fwxsign1.fsf@meyering.net> Lines: 46 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 6960 Cc: Matt McCutchen , 6960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -3.3 (---) Voelker, Bernhard wrote: > Jim Meyering wrote: > >> It is a deliberate feature. >> >> Personally, I prefer the semantics of 'mv -f --backup=numbered' >> so use a shell alias. > > just for fun I tried to get no backup created and tried '--backup=never', > but a backup is still created (version 8.5 on Cygwin, and 5.93 on SLES-10.3): > > $ uname -a > a > $ ln -s a b > $ mv -v --backup=never b a > `b' -> `a' (backup: `a~') > $ ls -l a a~ > lrwxrwxrwx 1 vb027591 ugrp 1 2010-09-02 11:50 a -> a > -rw-r--r--+ 1 vb027591 ugrp 69 2010-09-02 11:50 a~ > > I expected mv either to fail as if --backup=... is not given, > or that it moves the file without creating a backup. > > Maybe I'm a bit confused that the combination of the words "backup" > and "never" contrasts to what it does: it _creates_ a backup > - though mentioned in manual: > > $ man mv > ... > simple, never > always make simple backups > > Am I just misunderstanding the backup CONTROL "never"? --backup=never means "never make numbered backups; always make single backups", quoting emacs documentation (see 'Single or Numbered Backups' in info emacs). That's where that ambiguous name originated. Or perhaps more relevant, see "info coreutils mv": `simple' `never' Always make simple backups. Please note `never' is not to be confused with `none'. When in doubt, refer to the "info" documentation, not the man page. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 27 17:18:02 2011 Received: (at 6960) by debbugs.gnu.org; 27 Aug 2011 21:18:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QxQGP-0002kr-LE for submit@debbugs.gnu.org; Sat, 27 Aug 2011 17:18:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QxQGN-0002kb-HI; Sat, 27 Aug 2011 17:18:00 -0400 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 p7RLF6pD028226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Aug 2011 17:15:06 -0400 Received: from mx.meyering.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7RLF5me002282; Sat, 27 Aug 2011 17:15:06 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 2EC9A62226; Sat, 27 Aug 2011 23:15:05 +0200 (CEST) From: Jim Meyering To: Matt McCutchen Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <87sk1sin5b.fsf@meyering.net> (Jim Meyering's message of "Thu, 02 Sep 2010 10:07:44 +0200") References: <1283289668.1923.79.camel@mattlaptop2.local> <87sk1sin5b.fsf@meyering.net> Date: Sat, 27 Aug 2011 23:15:04 +0200 Message-ID: <87zkiusgiv.fsf@rho.meyering.net> Lines: 61 MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Spam-Score: -10.6 (----------) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -10.6 (----------) tags 6950 + notabug close 6950 thanks Jim Meyering wrote: > Matt McCutchen wrote: > >> If mv is asked to move a symlink over a hard link to the same file, it >> fails with the message, "A and B are the same file". There is no reason >> why it should complain rather than perform the move. > > Actually, there is a very good reason. See below. > >> Example: > ... >> $ touch New_York >> $ ln New_York localtime >> $ ln -s New_York localtime.new >> $ ls -l >> total 0 >> -rw------- 2 matt matt 0 2010-08-31 17:10 New_York >> -rw------- 2 matt matt 0 2010-08-31 17:10 localtime >> lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York >> $ ~/coreutils/coreutils.usr/bin/mv localtime.new localtime >> /home/matt/coreutils/coreutils.usr/bin/mv: `localtime.new' and >> localtime' are the same file > > Here, your regular file, New_York, happens to be empty. > That is a special, degenerate case. > If you lose this file, via use of mv, you lose nothing at all. > Well, in general, you might lose convenient access to the destination inode, > if it had two or more links. > But what if it contained a copy of some important document? > > > It is a problem of perception. > The user sees two files, A and B. > The naive user sees that they have the same contents, > but does not notice they are symlinked. May not even > know what a symlink is... > Our user decides to get rid of the duplicate. > > The lucky naive user moves the real file onto the symlink (say "mv A B") > and that succeeds. If however, s/he uses the other argument ordering > ("mv B A") and moves the symlink onto the real file, some versions > of "mv" would leave our poor user with no copy of the original file. > This is called "data loss" ;-) The user did nothing wrong, yet ended > up destroying what may have been important data. That is why GNU mv > deliberately refuses to perform the offending operation. > > One may argue that there is no data loss when the destination link count > is 2 or more, but once the destination has been unlinked, it may be very > challenging to locate another copy. > > This is not a bug in GNU mv. > It is a deliberate feature. > > Personally, I prefer the semantics of 'mv -f --backup=numbered' > so use a shell alias. There was no further discussion, so I've closed this. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 27 17:27:01 2011 Received: (at control) by debbugs.gnu.org; 27 Aug 2011 21:27:01 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QxQP6-0002xN-TE for submit@debbugs.gnu.org; Sat, 27 Aug 2011 17:27:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QxQP4-0002xG-Vy for control@debbugs.gnu.org; Sat, 27 Aug 2011 17:26:59 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7RLO685012044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 27 Aug 2011 17:24:06 -0400 Received: from mx.meyering.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7RLO5LO022627 for ; Sat, 27 Aug 2011 17:24:05 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id E674A60019 for ; Sat, 27 Aug 2011 23:24:04 +0200 (CEST) From: Jim Meyering To: control@debbugs.gnu.org Subject: correct bug number In-Reply-To: (GNU bug Tracking System's message of "Sat, 27 Aug 2011 17:19:02 -0400") References: <87zkiusgiv.fsf@rho.meyering.net> Date: Sat, 27 Aug 2011 23:24:04 +0200 Message-ID: <87ty92sg3v.fsf_-_@rho.meyering.net> Lines: 2 MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -10.6 (----------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -10.6 (----------) tags 6960 + notabug close 6960 From unknown Thu Sep 11 02:24:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 25 Sep 2011 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 15:14:48 2012 Received: (at control) by debbugs.gnu.org; 4 Jan 2012 20:14:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXEW-00066C-F6 for submit@debbugs.gnu.org; Wed, 04 Jan 2012 15:14:48 -0500 Received: from dmz-mailsec-scanner-5.mit.edu ([18.7.68.34]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXEV-000664-0n for control@debbugs.gnu.org; Wed, 04 Jan 2012 15:14:47 -0500 X-AuditID: 12074422-b7fd66d0000008f9-5d-4f04b268428f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.78.02297.862B40F4; Wed, 4 Jan 2012 15:11:20 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q04KBKj4023723 for ; Wed, 4 Jan 2012 15:11:20 -0500 Received: from localhost (LINERVA.MIT.EDU [18.181.0.232]) (authenticated bits=0) (User authenticated as andersk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q04KBJLm005012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 4 Jan 2012 15:11:20 -0500 (EST) Date: Wed, 4 Jan 2012 15:11:19 -0500 (EST) From: Anders Kaseorg To: control@debbugs.gnu.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUixCmqrJuxicXf4Nh0LYsbV2UdGD0uTtrH HMAYxWWTkpqTWZZapG+XwJWxeNsipgKJigttj1gbGIW7GDk5JARMJNY//MwOYYtJXLi3nq2L kYtDSGAfo0TrsZVQzllGif+zDjKDVAkJ3GSSWDfVC8RmEdCSmLzkIQuIzSagJjF3w2SgSRwc IgLSErNuq4OYvAKOEnM2e4NUiAroSmzuXsoGYvMKCEqcnPkErJMZaMry6dtYJjDyzEKSmoUk tYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZQSLC7KO1g/HlQ6RCjAAej Eg/vwwYWfyHWxLLiytxDjJIcTEqivFwbgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeLfOBMrx piRWVqUW5cOkpDlYlMR51bXe+QkJpCeWpGanphakFsFkZTg4lCR460CGChalpqdWpGXmlCCk mTg4QYbzAA03AqnhLS5IzC3OTIfIn2JUlBLn7QFJCIAkMkrz4HphMfuKURzoFWHeXJAqHmC8 w3W/AhrMBDQ4SgRscEkiQkqqgVEuTbklNO8OQ5b853kM8sv7Zn+V2vK3VDyZ5Vb+5YYDi2SP b6zmbcx43vMgmn9SRDRXU6X2vzBDgYRLNUGviqxzX4te+a/7ozG19G+0dqtOZEp2+2pWjdju hxbKB8/xsdzNblsnP2+1UGupzWSxy/PCBcTXPZxx6sl7mbO8h1/tYq9IcZpzQ4mlOCPRUIu5 qDgRAEKsRfS0AgAA X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -0.1 (/) unarchive 6960 thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 15:35:33 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 20:35:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXYb-0007UD-9I for submit@debbugs.gnu.org; Wed, 04 Jan 2012 15:35:33 -0500 Received: from dmz-mailsec-scanner-4.mit.edu ([18.9.25.15]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXYY-0007Ty-PV for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 15:35:31 -0500 X-AuditID: 1209190f-b7f8a6d000000914-9c-4f04b744d733 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.4A.02324.447B40F4; Wed, 4 Jan 2012 15:32:04 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q04KW4Hi011399 for <6960@debbugs.gnu.org>; Wed, 4 Jan 2012 15:32:04 -0500 Received: from localhost (LINERVA.MIT.EDU [18.181.0.232]) (authenticated bits=0) (User authenticated as andersk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q04KW33f008916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <6960@debbugs.gnu.org>; Wed, 4 Jan 2012 15:32:04 -0500 (EST) Date: Wed, 4 Jan 2012 15:32:02 -0500 (EST) From: Anders Kaseorg To: 6960@debbugs.gnu.org Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUixCmqreuyncXfYNlveYttR6ayODB6XJy0 jzmAMYrLJiU1J7MstUjfLoEr4/Cph6wFXVwVcy5ENTB2cnQxcnJICJhI3DmxhhHCFpO4cG89 WxcjF4eQwD5Gic6eRhYI5xSjxKXP25kgnGtMEjNf9jGDtLAIaEn07ZvNDmKzCahJzN0wGcjm 4BARkJB4MaUIJCwsEC6xsuE3G0iYV8BR4u/SLJCwqICuxObupWwgNq+AoMTJmU9YQGxmAXWJ A58uMkLY2hL3b7axTWDkm4WkbBaSsllIyhYwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdHL zSzRS00p3cQIDjBJ/h2M3w4qHWIU4GBU4uF92MDiL8SaWFZcmXuIUZKDSUmUd/VWoBBfUn5K ZUZicUZ8UWlOavEhRgkOZiUR3q0zgXK8KYmVValF+TApaQ4WJXFeNa13fkIC6YklqdmpqQWp RTBZNQ4OgUN98lIsefl5qUoSvDO2AY0QLEpNT61Iy8wpQShk4uAEWcMDtOYySA1vcUFibnFm OkT+FKMux8mtG84yCoENkhLnXQpSJABSlFGaBzcHlixeMYoDPSjMOxWkigeYaOAmvQJawgS0 JEoEbElJIkJKqoExM/rsjeSXEycF7ugqub334h+9wpIjmjMNWYK/ld71cVXasW82g+EOvf0X uvY373+w7FzOrlUeu1Y+6f97bc76/RXvXD8wbZ1qPkfy0oO0YE9Fn/ZZV7dG/9GYrfFE3kKh +vYBtb0cxoWP623Xa+549pGN49WO9XOL1JPNV9bt22Ra7SO0MbuHT4mlOCPRUIu5qDgRACY1 eAzxAgAA X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 6960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -2.4 (--) This refusal makes it impossible to overwrite a hard link with a symlink=20 _atomically_. See for example http://bugs.debian.org/654596 . In reply to message #17: > One may argue that there is no data loss when the destination link count= =20 > is 2 or more, but once the destination has been unlinked, it may be very= =20 > challenging to locate another copy. I would instead argue that there is no data loss when replacing a hard=20 link foo with a symlink to bar, as long as foo and bar are _different_=20 hard links to the same inode. In that case, locating the other copy is=20 not a problem because the symlink will still be valid. For example, in the example from the original report: -rw------- 2 matt matt 0 2010-08-31 17:10 New_York -rw------- 2 matt matt 0 2010-08-31 17:10 localtime lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York mv may reasonably refuse to overwrite New_York with localtime.new, but it= =20 should not refuse to overwrite localtime with localtime.new. > Personally, I prefer the semantics of 'mv -f --backup=3Dnumbered' so use = a=20 > shell alias. mv --backup=3Dnumbered is not atomic; it expands to two rename() syscalls,= =20 between which the target doesn=E2=80=99t exist at all. Anders From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 15:49:58 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 20:49:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXmY-00008M-IT for submit@debbugs.gnu.org; Wed, 04 Jan 2012 15:49:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXmV-00008E-Fe for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 15:49:57 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q04KkSpt010345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 15:46:28 -0500 Received: from [10.3.113.16] ([10.3.113.16]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q04KkR6I006759; Wed, 4 Jan 2012 15:46:28 -0500 Message-ID: <4F04BAA3.3010109@redhat.com> Date: Wed, 04 Jan 2012 13:46:27 -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 To: Anders Kaseorg Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file References: <1283289668.1923.79.camel@mattlaptop2.local> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig6C6C3C0774EC9DC54BE0BF6C" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Spam-Score: -10.4 (----------) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -10.4 (----------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6C6C3C0774EC9DC54BE0BF6C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/04/2012 01:32 PM, Anders Kaseorg wrote: > This refusal makes it impossible to overwrite a hard link with a symlin= k=20 > _atomically_. It is already impossible to overwrite a directory with a symlink atomically; then again, the only time rename() allows overwriting a directory is if it is empty, and removing an empty directory before putting a symlink in its place is not a form of data loss. But whether the inability to atomically overwrite a directory with a symlink should carry over to a refusal to atomically overwrite a regular file with a symlink is a different matter. >> Personally, I prefer the semantics of 'mv -f --backup=3Dnumbered' so u= se a=20 >> shell alias. >=20 > mv --backup=3Dnumbered is not atomic; it expands to two rename() syscal= ls,=20 > between which the target doesn=E2=80=99t exist at all. Maybe we should fix that, to make mv --backup use link()/rename() rather than rename()/rename(), so that there is no window where the target doesn't exist. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig6C6C3C0774EC9DC54BE0BF6C 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/ iQEcBAEBCAAGBQJPBLqjAAoJEKeha0olJ0Nq8dAIAKxHasOFfENrTYXCxV0M2IbX WL8ckkhx+XGyXAorJ3FFf0BYcs6XwikJPFItu7xQR1a9yG4mA3xUJSbzuAVTXIpk WFIR6b9wLJtSh5uHZtB7o5qfJ1ResqdYj+xOvdCR6DPDcHx0oe4lYAhqw+GLqtfi o052y4Fma4A29Db4nt44xIYG+MuBc+Zsn53m9JHf+S1UFfCwhfz3i1gNgHhz6zlC Oj9I6OTiwyquTXZEG1PCTeBENGiKhvOz9684jBIOU2JhF9Y0TceO4NUeqUFXibgM W5n/j2y0+oWEK53dAnPYBHsRm2U2//MDJ8k6uN/aEs8a4ShIHx1I5iO24QNjoGk= =qMqW -----END PGP SIGNATURE----- --------------enig6C6C3C0774EC9DC54BE0BF6C-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 15:57:23 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 20:57:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXtj-0000J6-E0 for submit@debbugs.gnu.org; Wed, 04 Jan 2012 15:57:23 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiXtg-0000Iy-DZ for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 15:57:21 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 865F560092; Wed, 4 Jan 2012 21:53:53 +0100 (CET) From: Jim Meyering To: Eric Blake Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <4F04BAA3.3010109@redhat.com> (Eric Blake's message of "Wed, 04 Jan 2012 13:46:27 -0700") References: <1283289668.1923.79.camel@mattlaptop2.local> <4F04BAA3.3010109@redhat.com> Date: Wed, 04 Jan 2012 21:53:53 +0100 Message-ID: <878vlnchpa.fsf@rho.meyering.net> Lines: 28 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, Anders Kaseorg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -2.8 (--) Eric Blake wrote: > On 01/04/2012 01:32 PM, Anders Kaseorg wrote: >> This refusal makes it impossible to overwrite a hard link with a symlink >> _atomically_. > > It is already impossible to overwrite a directory with a symlink > atomically; then again, the only time rename() allows overwriting a > directory is if it is empty, and removing an empty directory before > putting a symlink in its place is not a form of data loss. But whether > the inability to atomically overwrite a directory with a symlink should > carry over to a refusal to atomically overwrite a regular file with a > symlink is a different matter. > >>> Personally, I prefer the semantics of 'mv -f --backup=3Dnumbered' so us= e a >>> shell alias. >> >> mv --backup=3Dnumbered is not atomic; it expands to two rename() syscall= s, >> between which the target doesn=E2=80=99t exist at all. Oh! Amazing that suboptimal behavior has persisted in coreutils for so lon= g. > Maybe we should fix that, to make mv --backup use link()/rename() rather > than rename()/rename(), so that there is no window where the target > doesn't exist. No "maybe" about it ;-) I was already looking at that. It will be rather hairy, though. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 16:04:24 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 21:04:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiY0W-0001Dn-Fy for submit@debbugs.gnu.org; Wed, 04 Jan 2012 16:04:24 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiY0V-0001Dg-8F for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 16:04:23 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id BFFDC600E3; Wed, 4 Jan 2012 22:00:55 +0100 (CET) From: Jim Meyering To: Eric Blake Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <4F04BAA3.3010109@redhat.com> (Eric Blake's message of "Wed, 04 Jan 2012 13:46:27 -0700") References: <1283289668.1923.79.camel@mattlaptop2.local> <4F04BAA3.3010109@redhat.com> Date: Wed, 04 Jan 2012 22:00:55 +0100 Message-ID: <8739bvchdk.fsf@rho.meyering.net> Lines: 26 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, Anders Kaseorg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -2.8 (--) Eric Blake wrote: > On 01/04/2012 01:32 PM, Anders Kaseorg wrote: >> This refusal makes it impossible to overwrite a hard link with a symlink >> _atomically_. > > It is already impossible to overwrite a directory with a symlink > atomically; then again, the only time rename() allows overwriting a > directory is if it is empty, and removing an empty directory before > putting a symlink in its place is not a form of data loss. But whether > the inability to atomically overwrite a directory with a symlink should > carry over to a refusal to atomically overwrite a regular file with a > symlink is a different matter. > >>> Personally, I prefer the semantics of 'mv -f --backup=3Dnumbered' so us= e a >>> shell alias. >> >> mv --backup=3Dnumbered is not atomic; it expands to two rename() syscall= s, >> between which the target doesn=E2=80=99t exist at all. > > Maybe we should fix that, to make mv --backup use link()/rename() rather > than rename()/rename(), so that there is no window where the target > doesn't exist. Note that we can use link/rename only some of the time. E.g., the rename will always fail when they're on different partitions. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 16:09:35 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 21:09:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiY5X-0001M5-2b for submit@debbugs.gnu.org; Wed, 04 Jan 2012 16:09:35 -0500 Received: from dmz-mailsec-scanner-5.mit.edu ([18.7.68.34]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiY5U-0001Lx-Iy for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 16:09:33 -0500 X-AuditID: 12074422-b7fd66d0000008f9-a6-4f04bf3e2616 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id D9.2C.02297.E3FB40F4; Wed, 4 Jan 2012 16:06:06 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q04L65or015894; Wed, 4 Jan 2012 16:06:05 -0500 Received: from localhost (LINERVA.MIT.EDU [18.181.0.232]) (authenticated bits=0) (User authenticated as andersk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q04L63mn015622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2012 16:06:04 -0500 (EST) Date: Wed, 4 Jan 2012 16:06:03 -0500 (EST) From: Anders Kaseorg To: Eric Blake Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <4F04BAA3.3010109@redhat.com> Message-ID: References: <1283289668.1923.79.camel@mattlaptop2.local> <4F04BAA3.3010109@redhat.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrWu3n8XfYFIvm8W2I1NZLCa+Xc/q wORxcdI+Zo/3+66yBTBFcdmkpOZklqUW6dslcGUs/7KSueAIZ8W3eeeYGhhvsXcxcnJICJhI fLq6hxnCFpO4cG89WxcjF4eQwD5GiTuTpkI56xkljuw5xA7h7GaS+LHnPhtIC4uAlsT5nmus IDabgJrE3A2TwcaKCChJTF/WCGRzcDALSEisbGcCCQsLhEusbPgN1soJ1Lpp+QKwVl4BR4lv j9dCLethlDgz5QJYg6iArsTm7qVsEEWCEidnPmEBsZkF1CUOfLrICGFrS9y/2cY2gVFwFpKy WUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyMohNldlHYw/jyo dIhRgINRiYf3YQOLvxBrYllxZe4hRkkOJiVRXqV9QCG+pPyUyozE4oz4otKc1OJDjBIczEoi vFtnAuV4UxIrq1KL8mFS0hwsSuK86lrv/IQE0hNLUrNTUwtSi2CyMhwcShK84SBDBYtS01Mr 0jJzShDSTBycIMN5gIaHgNTwFhck5hZnpkPkTzFacixeteEsI8fJrSDy1z4gKcSSl5+XKiXO Gw/SIADSkFGaBzcTlpJeMYoDvSjMGwpSxQNMZ3BTXwEtZAJaGCUCtrAkESEl1cCom7atV7PR jfHIQ82MNZM0T19WftcjIqF5Y6X81xtxM4QdNZ4u2Rt1/wl3xpp600LW53/eHC54+uOhFf/k JfVJs4W6Pngfktramx90+k90atnZAG37/zc2zD8mLqDXvSX44/9Jl95N+hzJ5Kn3MO/XBY1C 5eka1ptjTBdbPw/6njfh85dv7c/LlViKMxINtZiLihMB8197jCQDAAA= X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -2.7 (--) On Wed, 4 Jan 2012, Eric Blake wrote: > But whether the inability to atomically overwrite a directory with a=20 > symlink should carry over to a refusal to atomically overwrite a regular= =20 > file with a symlink is a different matter. To be clear, mv is already perfectly happy to atomically overwrite a=20 regular file with a symlink (even if that causes data loss), as long as it= =20 doesn=E2=80=99t detect that the symlink points to the same inode. The only purpose given for this same-inode check is preventing a=20 particular kind of accident, and I claim that this purpose would be better= =20 served by a same-path check, because the same-inode-but-different-path=20 case is useful and can=E2=80=99t allow that kind of accident (and indeed, w= on=E2=80=99t=20 lose data at all). > Maybe we should fix that, to make mv --backup use link()/rename() rather > than rename()/rename(), so that there is no window where the target > doesn't exist. Perhaps, but that=E2=80=99s not a good solution to _this_ problem, because = a=20 script that wants to do this kind of atomic replacement would then need to= =20 go delete the backups (potentially resulting in more data loss). Anders From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 16:16:15 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 21:16:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiYBz-0002Fo-Oa for submit@debbugs.gnu.org; Wed, 04 Jan 2012 16:16:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiYBx-0002Fh-C2 for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 16:16:15 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q04LCkk5007443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 16:12:46 -0500 Received: from [10.3.113.16] ([10.3.113.16]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q04LCjAP003631; Wed, 4 Jan 2012 16:12:45 -0500 Message-ID: <4F04C0CD.3020000@redhat.com> Date: Wed, 04 Jan 2012 14:12:45 -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 To: Jim Meyering Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file References: <1283289668.1923.79.camel@mattlaptop2.local> <4F04BAA3.3010109@redhat.com> <8739bvchdk.fsf@rho.meyering.net> In-Reply-To: <8739bvchdk.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF5BFBD819D4DAF0AA222D514" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -10.4 (----------) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, Anders Kaseorg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -10.4 (----------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF5BFBD819D4DAF0AA222D514 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/04/2012 02:00 PM, Jim Meyering wrote: >>> mv --backup=3Dnumbered is not atomic; it expands to two rename() sysc= alls, >>> between which the target doesn=E2=80=99t exist at all. >> >> Maybe we should fix that, to make mv --backup use link()/rename() rath= er >> than rename()/rename(), so that there is no window where the target >> doesn't exist. >=20 > Note that we can use link/rename only some of the time. > E.g., the rename will always fail when they're on different partitions.= It's a two-edged sword - POSIX _requires_ mv(1) to be atomic (no period where target does not exist) if no EXDEV would occur from rename(2), but does _not_ require atomicity otherwise. If rename(2) fails because you cross partitions, then you already _expect_ a window where the target is bogus, per the POSIX requirements on mv(1); so whether we rename()/creat() or link()/unlink()/creat(), the behavior is the same. Is it worth shaving off the extra syscall by using rename(target,target-backup) instead of link()/unlink() when we can detect a-priori that rename(source,target) would fail with EXDEV? Or should we _always_ favor link(target,target-backup), and only if the rename(source,target) fails do we fall back to unlink(target) followed by creating the file with the moved contents? Or do we go one step further, and guarantee atomicity even where POSIX does not require it in the EXDEV situation, by doing: link(target,target-backup) creat(temp) in dirname(target) copy source to temp rename(temp,target) Then again, that takes up more disk space when there is no target-backup created, so it seems like it might be worth providing that extra level of atomicity guarantees only via a command line option. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigF5BFBD819D4DAF0AA222D514 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/ iQEcBAEBCAAGBQJPBMDNAAoJEKeha0olJ0NqYEUH/Ajo99+gjS4SDlLCu7oJEInZ uJlu3vrVOV8KN71E2bs1n5eGU9VB1RYaNtdgjWKJyZ38+0k00Tw7k0DeoAHf23lZ Vz27ohbPzz6tJZaJ7kGjetM6Egl5Gy8C5fOMJgl/tb9FM01chu4T4kOjVW0EpXc8 DWSgsR5TJf4BdtQIB69Own4v0bRlHsi/+rE3RiWTF+EnUVfL/rFvsJJ4yB7+D5/Y I4HewYNsInEnsrQwgesxDeRsdUw2tclheYs//MCXL3aLGABMRhfvZEVf/Ahvus36 jrmbN+CLM3u4ckEYh3WAdkJMtC9m/yfa3v9A14l/WT7LC+lJJiinZEiWfU8eXlo= =eK8N -----END PGP SIGNATURE----- --------------enigF5BFBD819D4DAF0AA222D514-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 16:56:43 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 21:56:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiYp9-0003Ck-2s for submit@debbugs.gnu.org; Wed, 04 Jan 2012 16:56:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiYp5-0003CW-78; Wed, 04 Jan 2012 16:56:41 -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 q04LrAdd009797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 16:53:12 -0500 Received: from [10.3.113.16] ([10.3.113.16]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q04L1q12017123; Wed, 4 Jan 2012 16:01:52 -0500 Message-ID: <4F04BE40.5040302@redhat.com> Date: Wed, 04 Jan 2012 14:01:52 -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 To: Jim Meyering Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file References: <1283289668.1923.79.camel@mattlaptop2.local> <4F04BAA3.3010109@redhat.com> <878vlnchpa.fsf@rho.meyering.net> In-Reply-To: <878vlnchpa.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig97F88CB9F7CA22FEFB254AAC" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Spam-Score: -10.4 (----------) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, Anders Kaseorg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -10.4 (----------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig97F88CB9F7CA22FEFB254AAC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable tag 6960 - notabug reopen 6960 thanks On 01/04/2012 01:53 PM, Jim Meyering wrote: >>> mv --backup=3Dnumbered is not atomic; it expands to two rename() sysc= alls, >>> between which the target doesn=E2=80=99t exist at all. >=20 > Oh! Amazing that suboptimal behavior has persisted in coreutils for so= long. >=20 >> Maybe we should fix that, to make mv --backup use link()/rename() rath= er >> than rename()/rename(), so that there is no window where the target >> doesn't exist. >=20 > No "maybe" about it ;-) In which case we'd better reopen this bug. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig97F88CB9F7CA22FEFB254AAC 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/ iQEcBAEBCAAGBQJPBL5AAAoJEKeha0olJ0NqSpQIAJqfOhrEUlAMbbRXbpaFORLY C2He8n36o5dt8TH1Fq//FMUWl5t9OUrH1eOuzRd9EdCyywyxth+IthHN+aCbX0ke 3r2+vtUSvJv5z7YvjCFbQ7J+rGg5lo7exIAmcOHTRQFFzGRIk9/kyGgTMqSh9Imx Fx8yNnl7T9C7M8rM9gsY5mkuyiKTb3mCpDh0b80hUq/+idOk7PybLzv6kirBpezL PxMpMqtKD+sZm1httu3eq/3NDFpdRK35YqilgqfjAWgD0EKpk2ifNgdGxtcd0nLk Y3AknFY7YsQVjqXy+qWqpTLMxWENHEuDVY1RLo4no7bKY0pBNyXSQnTOYyM5/fo= =1Lt2 -----END PGP SIGNATURE----- --------------enig97F88CB9F7CA22FEFB254AAC-- From unknown Thu Sep 11 02:24:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Wed, 04 Jan 2012 21:57:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 17:33:48 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 22:33:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiZP1-0004o5-UX for submit@debbugs.gnu.org; Wed, 04 Jan 2012 17:33:48 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiZOy-0004nv-9y for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 17:33:46 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 0765D600E3; Wed, 4 Jan 2012 23:30:16 +0100 (CET) From: Jim Meyering To: Anders Kaseorg Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: (Anders Kaseorg's message of "Wed, 4 Jan 2012 15:32:02 -0500 (EST)") References: <1283289668.1923.79.camel@mattlaptop2.local> Date: Wed, 04 Jan 2012 23:30:16 +0100 Message-ID: <87obujayo7.fsf@rho.meyering.net> Lines: 106 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -2.8 (--) Anders Kaseorg wrote: > This refusal makes it impossible to overwrite a hard link with a symlink > _atomically_. > > See for example http://bugs.debian.org/654596 . > > In reply to message #17: >> One may argue that there is no data loss when the destination link count >> is 2 or more, but once the destination has been unlinked, it may be very >> challenging to locate another copy. > > I would instead argue that there is no data loss when replacing a hard > link foo with a symlink to bar, as long as foo and bar are _different_ > hard links to the same inode. In that case, locating the other copy is > not a problem because the symlink will still be valid. > > For example, in the example from the original report: > -rw------- 2 matt matt 0 2010-08-31 17:10 New_York > -rw------- 2 matt matt 0 2010-08-31 17:10 localtime > lrwxrwxrwx 1 matt matt 8 2010-08-31 17:11 localtime.new -> New_York > mv may reasonably refuse to overwrite New_York with localtime.new, but it > should not refuse to overwrite localtime with localtime.new. This sounds reasonable. Implementing it may even be easy -- for some inputs. However, in general, we'll have to find a way to accept this: mv localtime.new localtime without also accepting this: mv localtime.new New_York That latter command would leave New_York as a symlink to itself, with the sole remaining link being "localtime". Any solution must ensure that the destination and the referent of source symlink are not the same entry. We even have a function for that, once you find the referent's name: same_name (in lib/same.c). Sounds trivial, but the catch is how to find the referent's name *in general*. What if localtime.new points to a symlink, foo->bar->New_York ? Then, in order to answer that question, we have to be able to traverse an arbitrarily-long chain of symlinks. What if there's a loop by the time we start traversing? None of these are insurmountable, but they give you an idea of the amount of complexity that seems (at least to me) to be required. You could form the symlink-free full name of the referent, abs_src and then test same_name (abs_src, dst_name). I've just done it: With this patch, cp still passes all of coreutils tests as well as the one described in the comments below: (take this with a grain of salt -- it's seen only minimal testing so far) diff --git a/src/copy.c b/src/copy.c index 4255d74..41ee3a6 100644 --- a/src/copy.c +++ b/src/copy.c @@ -34,6 +34,7 @@ #include "acl.h" #include "backupfile.h" #include "buffer-lcm.h" +#include "canonicalize.h" #include "copy.h" #include "cp-hash.h" #include "extent-scan.h" @@ -1349,6 +1350,37 @@ same_file_ok (char const *src_name, struct stat const *src_sb, } } + /* In move mode, when + src is a symlink, + dest is not a symlink, + dest has a link count of 2 or more and + dest and the referent of src are not the same entry (Hard part), + then it's ok, since while we'll lose one of those hard links, + src will still point to a remaining link. + + Given this, + $ touch f && ln f l && ln -s f s + $ ls -og f l s + -rw-------. 2 0 Jan 4 22:46 f + -rw-------. 2 0 Jan 4 22:46 l + lrwxrwxrwx. 1 1 Jan 4 22:46 s -> f + this must fail: mv s f + this must succeed: mv s l */ + if (x->dereference == DEREF_NEVER /* FIXME, reconsider this part */ + && x->move_mode + && S_ISLNK (src_sb->st_mode) + && ! S_ISLNK (dst_sb->st_mode) + && 1 < dst_sb_link->st_nlink) + { + char *abs_src = canonicalize_file_name (src_name); + if (abs_src) + { + bool result = ! same_name (abs_src, dst_name); + free (abs_src); + return result; + } + } + /* It's ok to remove a destination symlink. But that works only when we unlink before opening the destination and when the source and destination files are on the same partition. */ From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 04 17:56:06 2012 Received: (at 6960) by debbugs.gnu.org; 4 Jan 2012 22:56:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiZkb-0005Ib-B2 for submit@debbugs.gnu.org; Wed, 04 Jan 2012 17:56:06 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RiZkX-0005IA-DU for 6960@debbugs.gnu.org; Wed, 04 Jan 2012 17:56:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A76ACA60002; Wed, 4 Jan 2012 14:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdMJ1htYAzWc; Wed, 4 Jan 2012 14:52:33 -0800 (PST) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 31C9039E8008; Wed, 4 Jan 2012 14:52:33 -0800 (PST) Message-ID: <4F04D82C.2070508@cs.ucla.edu> Date: Wed, 04 Jan 2012 14:52:28 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> In-Reply-To: <87obujayo7.fsf@rho.meyering.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, Anders Kaseorg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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: -2.9 (--) On 01/04/12 14:30, Jim Meyering wrote: > You could form the symlink-free full name of the referent, abs_src > and then test same_name (abs_src, dst_name). That doesn't sound right, since the symlink may resolve differently after it's moved. For example: $ ls -ldt lt ny d d/lt.new drwxr-xr-x. 2 eggert eggert 4096 Jan 4 14:44 d lrwxrwxrwx. 1 eggert eggert 2 Jan 4 14:26 d/lt.new -> ny -rw-r--r--. 2 eggert eggert 2 Jan 4 14:26 lt -rw-r--r--. 2 eggert eggert 2 Jan 4 14:26 ny $ mv d/lt.new ny $ ls -ltd lt ny lrwxrwxrwx. 1 eggert eggert 2 Jan 4 14:26 ny -> ny -rw-r--r--. 1 eggert eggert 2 Jan 4 14:26 lt This scenario is almost equivalent to the problematic one in the original bug report, the one where 'mv' refuses to move, and yet here 'mv' charges right ahead. I'm becoming more inclined to think that Anders's argument: > mv is already perfectly happy to atomically overwrite a > regular file with a symlink (even if that causes data loss) is a valid one. Currently 'mv' is pretty complicated in this area, so complicated that I can't easily suggest a fix, but I'm starting to think that mv shouldn't reject either "mv localtime.new localtime" or "mv localtime.new New_York" in Anders's scenario. That is, it should simply compare inode numbers without dereferencing them. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 29 16:33:24 2012 Received: (at 6960) by debbugs.gnu.org; 29 Jan 2012 21:33:24 +0000 Received: from localhost ([127.0.0.1]:44137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrcNE-0002JM-VI for submit@debbugs.gnu.org; Sun, 29 Jan 2012 16:33:24 -0500 Received: from mx.meyering.net ([88.168.87.75]:46415) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrcN8-0002J8-PG for 6960@debbugs.gnu.org; Sun, 29 Jan 2012 16:33:19 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 181BF6019E; Sun, 29 Jan 2012 22:33:05 +0100 (CET) From: Jim Meyering To: Paul Eggert Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <4F04D82C.2070508@cs.ucla.edu> (Paul Eggert's message of "Wed, 04 Jan 2012 14:52:28 -0800") References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> <4F04D82C.2070508@cs.ucla.edu> Date: Sun, 29 Jan 2012 22:33:05 +0100 Message-ID: <87obtmnqi6.fsf@rho.meyering.net> Lines: 246 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, Anders Kaseorg 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 (-) Paul Eggert wrote: > On 01/04/12 14:30, Jim Meyering wrote: >> You could form the symlink-free full name of the referent, abs_src >> and then test same_name (abs_src, dst_name). > > That doesn't sound right, since the symlink may resolve differently > after it's moved. For example: Hi Paul, Interesting point. Thanks. > $ ls -ldt lt ny d d/lt.new > drwxr-xr-x. 2 eggert eggert 4096 Jan 4 14:44 d > lrwxrwxrwx. 1 eggert eggert 2 Jan 4 14:26 d/lt.new -> ny > -rw-r--r--. 2 eggert eggert 2 Jan 4 14:26 lt > -rw-r--r--. 2 eggert eggert 2 Jan 4 14:26 ny > $ mv d/lt.new ny However, your example is not relevant, because the source is a mere dangling symlink. Thus, it doesn't meet the requirements for that similarity check to be invoked. Perhaps you meant something like this: $ rm -f [dfgs]; mkdir d; touch f; ln f g; ln -s ../f d/k; env mv d/k g mv: 'd/k' and 'g' are the same file $ ls -ogi f g d/k 75574240 lrwxrwxrwx. 1 4 Jan 29 19:43 d/k -> ../f 75574239 -rw-------. 2 0 Jan 29 19:43 f 75574239 -rw-------. 2 0 Jan 29 19:43 g And in that case, I find it hard to imagine a legitimate use in which one would want to move such a relative symlink onto its referent at a different level of the hierarchy. So maybe we don't need to add a conjunct for that case after all. ... > I'm becoming more inclined to think that Anders's argument: > >> mv is already perfectly happy to atomically overwrite a >> regular file with a symlink (even if that causes data loss) > > is a valid one. If your/Anders' point is that moving an arbitrary symlink onto an unrelated regular file can unlink the final copy of the target, well, yes, that's true, but there's nothing subtle or unusual about that case, while there is in the cases that mv does reject. mv calls rename, so of course it must induce data loss. The point of this exception is to reject the very few cases that indicate user error with very high probability. Here's a more complete patch: >From 799b7f7c6f27a5356e76861066dfa554d3951f0d Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 5 Jan 2012 11:45:50 +0100 Subject: [PATCH] mv: allow moving symlink onto same-inode dest with >= 2 hard links Normally, mv detects a few subtle cases in which proceeding with a same-file rename would, with very high probability, cause data loss. Here, we have found a corner case in which one of these same-inode tests makes mv refuse to perform a useful operation. Permit that corner case. * src/copy.c (same_file_ok): Detect/exempt this case. * tests/mv/symlink-onto-hardlink: New test. * tests/Makefile.am (TESTS): Add it. * NEWS (Bug fixes): Mention it. Initially reported by: Matt McCutchen in http://bugs.gnu.org/6960. Raised again by Anders Kaseorg due to http://bugs.debian.org/654596. --- NEWS | 9 ++++++++ THANKS.in | 2 + src/copy.c | 37 ++++++++++++++++++++++++++++++++++++ tests/Makefile.am | 1 + tests/mv/symlink-onto-hardlink | 41 ++++++++++++++++++++++++++++++++++++++++ 5 files changed, 90 insertions(+), 0 deletions(-) create mode 100755 tests/mv/symlink-onto-hardlink diff --git a/NEWS b/NEWS index 2b0926f..9eebbf6 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,15 @@ GNU coreutils NEWS -*- outline -*- * Noteworthy changes in release ?.? (????-??-??) [?] +** Bug fixes + + mv now lets you move a symlink onto a same-inode destination file that + has two or more hard links. Before, it would reject that, saying that + they are the same, implicitly warning you that the move would result in + data loss. In this unusual case, when not moving the symlink onto its + referent, there is no risk of data loss, since the symlink will + typically still point to one of the hard links. + * Noteworthy changes in release 8.15 (2012-01-06) [stable] diff --git a/THANKS.in b/THANKS.in index 13c8817..904bb3e 100644 --- a/THANKS.in +++ b/THANKS.in @@ -39,6 +39,7 @@ Alexey Vyskubov alexey@pippuri.mawhrin.net Alfred M. Szmidt ams@kemisten.nu Ambrose Feinstein ambrose@google.com Amr Ali amr.ali.cc@gmail.com +Anders Kaseorg andersk@mit.edu Andi Kleen freitag@alancoxonachip.com Andre Novaes Cunha Andre.Cunha@br.global-one.net Andreas Frische andreasfrische@gmail.com @@ -384,6 +385,7 @@ Mate Wierdl mw@moni.msci.memphis.edu Matej Vela mvela@public.srce.hr Matias A. Fonzo selk@dragora.org Matt Kraai kraai@ftbfs.org +Matt McCutchen matt@mattmccutchen.net Matt Perry matt@primefactor.com Matt Pham mattvpham@gmail.com Matt Schalit mschalit@pacbell.net diff --git a/src/copy.c b/src/copy.c index 51f51be..af79ed3 100644 --- a/src/copy.c +++ b/src/copy.c @@ -34,6 +34,7 @@ #include "acl.h" #include "backupfile.h" #include "buffer-lcm.h" +#include "canonicalize.h" #include "copy.h" #include "cp-hash.h" #include "extent-scan.h" @@ -1349,6 +1350,38 @@ same_file_ok (char const *src_name, struct stat const *src_sb, } } + /* At this point, it is normally an error (data loss) to move a symlink + onto its referent, but in at least one narrow case, it is not: + In move mode, when + src is a symlink, + dest is not a symlink, + dest has a link count of 2 or more and + dest and the referent of src are not the same entry, + then it's ok, since while we'll lose one of those hard links, + src will still point to a remaining link. + + Given this, + $ touch f && ln f l && ln -s f s + $ ls -og f l s + -rw-------. 2 0 Jan 4 22:46 f + -rw-------. 2 0 Jan 4 22:46 l + lrwxrwxrwx. 1 1 Jan 4 22:46 s -> f + this must fail: mv s f + this must succeed: mv s l */ + if (x->move_mode + && S_ISLNK (src_sb->st_mode) + && ! S_ISLNK (dst_sb->st_mode) + && 1 < dst_sb_link->st_nlink) + { + char *abs_src = canonicalize_file_name (src_name); + if (abs_src) + { + bool result = ! same_name (abs_src, dst_name); + free (abs_src); + return result; + } + } + /* It's ok to remove a destination symlink. But that works only when we unlink before opening the destination and when the source and destination files are on the same partition. */ @@ -1837,6 +1870,10 @@ copy_internal (char const *src_name, char const *dst_name, to use fts, so using alloca here will be less of a problem. */ ASSIGN_STRDUPA (dst_backup, tmp_backup); free (tmp_backup); + /* In move mode, when src_name and dst_name are on the + same partition (FIXME, and when they are non-directories), + make the operation atomic: link dest + to backup, then rename src to dest. */ if (rename (dst_name, dst_backup) != 0) { if (errno != ENOENT) diff --git a/tests/Makefile.am b/tests/Makefile.am index 8b670fc..a94aaa2 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -491,6 +491,7 @@ TESTS = \ mv/part-symlink \ mv/partition-perm \ mv/perm-1 \ + mv/symlink-onto-hardlink \ mv/to-symlink \ mv/trailing-slash \ mv/update \ diff --git a/tests/mv/symlink-onto-hardlink b/tests/mv/symlink-onto-hardlink new file mode 100755 index 0000000..2dac484 --- /dev/null +++ b/tests/mv/symlink-onto-hardlink @@ -0,0 +1,41 @@ +#!/bin/sh +# Ensure that mv works with a few symlink-onto-hard-link cases. + +# 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 + +touch f || framework_failure_ +ln f h || framework_failure_ +ln -s f s || framework_failure_ + +# Given two links f and h to some important content, and a symlink s to f, +# "mv s f" must fail because it might then be hard to find the link, h. +# "mv s l" may succeed because then, s (now "l") still points to f. +# Of course, if the symlink were being moved into a different destination +# directory, things would be very different, and, I suspect, implausible. + +echo "mv: 's' and 'f' are the same file" > exp || framework_failure_ +mv s f > out 2> err && fail=1 +compare /dev/null out || fail=1 +compare exp err || fail=1 + +mv s l > out 2> err || fail=1 +compare /dev/null out || fail=1 +compare /dev/null err || fail=1 + +Exit $fail -- 1.7.9.1.g63eb From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 29 17:06:00 2012 Received: (at 6960) by debbugs.gnu.org; 29 Jan 2012 22:06:00 +0000 Received: from localhost ([127.0.0.1]:44166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rrcsp-00037S-KZ for submit@debbugs.gnu.org; Sun, 29 Jan 2012 17:06:00 -0500 Received: from mail2.vodafone.ie ([213.233.128.44]:11992) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rrcsn-00037C-Cx for 6960@debbugs.gnu.org; Sun, 29 Jan 2012 17:05:58 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACzCJU9tTEVT/2dsb2JhbAAMN6wmhSkBAQEDAScLAUYFCwsNFBYPCQMCAQIBRQYNAQcBAYd4t26IPQEDAgIECgIBDAQDBAsKNYJyHQIKFlgCCiyDNwSbEoxZ Received: from unknown (HELO [192.168.1.79]) ([109.76.69.83]) by mail2.vodafone.ie with ESMTP; 29 Jan 2012 22:05:44 +0000 Message-ID: <4F25C2B8.3070000@draigBrady.com> Date: Sun, 29 Jan 2012 22:05:44 +0000 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> <4F04D82C.2070508@cs.ucla.edu> <87obtmnqi6.fsf@rho.meyering.net> In-Reply-To: <87obtmnqi6.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 6960 Cc: Paul Eggert , 6960@debbugs.gnu.org, Anders Kaseorg 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 01/29/2012 09:33 PM, Jim Meyering wrote: > diff --git a/src/copy.c b/src/copy.c > index 51f51be..af79ed3 100644 > --- a/src/copy.c > +++ b/src/copy.c > @@ -34,6 +34,7 @@ > #include "acl.h" > #include "backupfile.h" > #include "buffer-lcm.h" > +#include "canonicalize.h" > #include "copy.h" > #include "cp-hash.h" > #include "extent-scan.h" > @@ -1349,6 +1350,38 @@ same_file_ok (char const *src_name, struct stat const *src_sb, > } > } > > + /* At this point, it is normally an error (data loss) to move a symlink > + onto its referent, but in at least one narrow case, it is not: > + In move mode, when > + src is a symlink, > + dest is not a symlink, > + dest has a link count of 2 or more and > + dest and the referent of src are not the same entry, > + then it's ok, since while we'll lose one of those hard links, > + src will still point to a remaining link. > + > + Given this, > + $ touch f && ln f l && ln -s f s > + $ ls -og f l s > + -rw-------. 2 0 Jan 4 22:46 f > + -rw-------. 2 0 Jan 4 22:46 l > + lrwxrwxrwx. 1 1 Jan 4 22:46 s -> f > + this must fail: mv s f > + this must succeed: mv s l */ > + if (x->move_mode > + && S_ISLNK (src_sb->st_mode) > + && ! S_ISLNK (dst_sb->st_mode) > + && 1 < dst_sb_link->st_nlink) > + { > + char *abs_src = canonicalize_file_name (src_name); > + if (abs_src) > + { > + bool result = ! same_name (abs_src, dst_name); > + free (abs_src); > + return result; > + } > + } Well the logic follows the description at least. I was going to say the nlink test was redundant, but it's a bit clearer with that left, and also it's a performance improvement in the nlink=1 case. cheers, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 30 04:04:55 2012 Received: (at 6960) by debbugs.gnu.org; 30 Jan 2012 09:04:55 +0000 Received: from localhost ([127.0.0.1]:44582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrnAU-0003QH-7Q for submit@debbugs.gnu.org; Mon, 30 Jan 2012 04:04:55 -0500 Received: from mx.meyering.net ([88.168.87.75]:48029) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrnAP-0003Q4-FT for 6960@debbugs.gnu.org; Mon, 30 Jan 2012 04:04:53 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id D0AE4600A3; Mon, 30 Jan 2012 10:04:36 +0100 (CET) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <4F25C2B8.3070000@draigBrady.com> (=?iso-8859-1?Q?=22P=E1drai?= =?iso-8859-1?Q?g?= Brady"'s message of "Sun, 29 Jan 2012 22:05:44 +0000") References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> <4F04D82C.2070508@cs.ucla.edu> <87obtmnqi6.fsf@rho.meyering.net> <4F25C2B8.3070000@draigBrady.com> Date: Mon, 30 Jan 2012 10:04:36 +0100 Message-ID: <874nvdo923.fsf@rho.meyering.net> Lines: 48 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 6960 Cc: Paul Eggert , 6960@debbugs.gnu.org, Anders Kaseorg 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 (-) P=E1draig Brady wrote: > On 01/29/2012 09:33 PM, Jim Meyering wrote: .. >> + /* At this point, it is normally an error (data loss) to move a symli= nk >> + onto its referent, but in at least one narrow case, it is not: >> + In move mode, when >> + src is a symlink, >> + dest is not a symlink, >> + dest has a link count of 2 or more and >> + dest and the referent of src are not the same entry, >> + then it's ok, since while we'll lose one of those hard links, >> + src will still point to a remaining link. >> + >> + Given this, >> + $ touch f && ln f l && ln -s f s >> + $ ls -og f l s >> + -rw-------. 2 0 Jan 4 22:46 f >> + -rw-------. 2 0 Jan 4 22:46 l >> + lrwxrwxrwx. 1 1 Jan 4 22:46 s -> f >> + this must fail: mv s f >> + this must succeed: mv s l */ >> + if (x->move_mode >> + && S_ISLNK (src_sb->st_mode) >> + && ! S_ISLNK (dst_sb->st_mode) >> + && 1 < dst_sb_link->st_nlink) >> + { >> + char *abs_src =3D canonicalize_file_name (src_name); >> + if (abs_src) >> + { >> + bool result =3D ! same_name (abs_src, dst_name); >> + free (abs_src); >> + return result; >> + } >> + } > > Well the logic follows the description at least. > I was going to say the nlink test was redundant, > but it's a bit clearer with that left, and also > it's a performance improvement in the nlink=3D1 case. Thanks for the review. I'll wait a day or so more, in case Paul or anyone else has feedback. BTW, I removed the x->dereference =3D=3D DEREF_NEVER test that I'd used in the first version, since in move mode, that condition is always true. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 30 06:41:31 2012 Received: (at 6960) by debbugs.gnu.org; 30 Jan 2012 11:41:31 +0000 Received: from localhost ([127.0.0.1]:44829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rrpc2-0007D0-T2 for submit@debbugs.gnu.org; Mon, 30 Jan 2012 06:41:31 -0500 Received: from mx.meyering.net ([88.168.87.75]:48430) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rrpbz-0007Cq-GQ for 6960@debbugs.gnu.org; Mon, 30 Jan 2012 06:41:28 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 3567660111; Mon, 30 Jan 2012 12:41:16 +0100 (CET) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <4F25C2B8.3070000@draigBrady.com> (=?iso-8859-1?Q?=22P=E1drai?= =?iso-8859-1?Q?g?= Brady"'s message of "Sun, 29 Jan 2012 22:05:44 +0000") References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> <4F04D82C.2070508@cs.ucla.edu> <87obtmnqi6.fsf@rho.meyering.net> <4F25C2B8.3070000@draigBrady.com> Date: Mon, 30 Jan 2012 12:41:16 +0100 Message-ID: <87mx95mn8j.fsf@rho.meyering.net> Lines: 73 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 6960 Cc: Paul Eggert , 6960@debbugs.gnu.org, Anders Kaseorg 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 (-) P=E1draig Brady wrote: > On 01/29/2012 09:33 PM, Jim Meyering wrote: > >> diff --git a/src/copy.c b/src/copy.c >> index 51f51be..af79ed3 100644 >> --- a/src/copy.c >> +++ b/src/copy.c >> @@ -34,6 +34,7 @@ >> #include "acl.h" >> #include "backupfile.h" >> #include "buffer-lcm.h" >> +#include "canonicalize.h" >> #include "copy.h" >> #include "cp-hash.h" >> #include "extent-scan.h" >> @@ -1349,6 +1350,38 @@ same_file_ok (char const *src_name, struct stat c= onst *src_sb, >> } >> } >> >> + /* At this point, it is normally an error (data loss) to move a symli= nk >> + onto its referent, but in at least one narrow case, it is not: >> + In move mode, when >> + src is a symlink, >> + dest is not a symlink, >> + dest has a link count of 2 or more and >> + dest and the referent of src are not the same entry, >> + then it's ok, since while we'll lose one of those hard links, >> + src will still point to a remaining link. >> + >> + Given this, >> + $ touch f && ln f l && ln -s f s >> + $ ls -og f l s >> + -rw-------. 2 0 Jan 4 22:46 f >> + -rw-------. 2 0 Jan 4 22:46 l >> + lrwxrwxrwx. 1 1 Jan 4 22:46 s -> f >> + this must fail: mv s f >> + this must succeed: mv s l */ >> + if (x->move_mode >> + && S_ISLNK (src_sb->st_mode) >> + && ! S_ISLNK (dst_sb->st_mode) >> + && 1 < dst_sb_link->st_nlink) >> + { >> + char *abs_src =3D canonicalize_file_name (src_name); >> + if (abs_src) >> + { >> + bool result =3D ! same_name (abs_src, dst_name); >> + free (abs_src); >> + return result; >> + } >> + } > > Well the logic follows the description at least. > I was going to say the nlink test was redundant, > but it's a bit clearer with that left, and also > it's a performance improvement in the nlink=3D1 case. That's a good point. I've added it: /* At this point, it is normally an error (data loss) to move a symlink onto its referent, but in at least one narrow case, it is not: In move mode, when 1) src is a symlink, 2) dest is not a symlink, 3) dest has a link count of 2 or more and 4) dest and the referent of src are not the same entry, then it's ok, since while we'll lose one of those hard links, src will still point to a remaining link. Note that technically, condition #4 obviates condition #2, but we retain the 1 < st_nlink condition because that means fewer invocations of the more expensive #4. ... From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 30 12:46:45 2012 Received: (at 6960) by debbugs.gnu.org; 30 Jan 2012 17:46:45 +0000 Received: from localhost ([127.0.0.1]:45468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrvJV-00087X-Ad for submit@debbugs.gnu.org; Mon, 30 Jan 2012 12:46:45 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:53568) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrvJS-000878-H5 for 6960@debbugs.gnu.org; Mon, 30 Jan 2012 12:46:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 80605A60010; Mon, 30 Jan 2012 09:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSegYkufG9IN; Mon, 30 Jan 2012 09:46:25 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 294ECA6000E; Mon, 30 Jan 2012 09:46:25 -0800 (PST) Message-ID: <4F26D770.8000207@cs.ucla.edu> Date: Mon, 30 Jan 2012 09:46:24 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> <4F04D82C.2070508@cs.ucla.edu> <87obtmnqi6.fsf@rho.meyering.net> <4F25C2B8.3070000@draigBrady.com> <87mx95mn8j.fsf@rho.meyering.net> In-Reply-To: <87mx95mn8j.fsf@rho.meyering.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, =?ISO-8859-1?Q?P=E1draig_Brady?= , Anders Kaseorg 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 01/30/2012 03:41 AM, Jim Meyering wrote: > /* At this point, it is normally an error (data loss) to move a symlink > onto its referent, but in at least one narrow case, it is not: > In move mode, when > 1) src is a symlink, > 2) dest is not a symlink, > 3) dest has a link count of 2 or more and > 4) dest and the referent of src are not the same entry, > then it's ok, since while we'll lose one of those hard links, > src will still point to a remaining link. > Note that technically, condition #4 obviates condition #2, but we > retain the 1 < st_nlink condition because that means fewer invocations > of the more expensive #4. The last 3 lines are confusing. Don't you mean "condition #3" and not "condition #2"? The last 2 lines talk about condition 3, not condition 2. Come to think of it, why is condition 2 needed at all? Can't we eliminate it, both in the commentary and in the code? If a symlink has a link count greater than 1, then overwriting it won't lose the link; in that sense it's just like a regular file with a link count greater than 1. So why are symlinks special there? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 30 14:42:49 2012 Received: (at 6960) by debbugs.gnu.org; 30 Jan 2012 19:42:49 +0000 Received: from localhost ([127.0.0.1]:45623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rrx7p-0003Hn-5N for submit@debbugs.gnu.org; Mon, 30 Jan 2012 14:42:49 -0500 Received: from mx.meyering.net ([88.168.87.75]:49734) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rrx7j-0003Ha-R3 for 6960@debbugs.gnu.org; Mon, 30 Jan 2012 14:42:47 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id C0131600A5; Mon, 30 Jan 2012 20:42:31 +0100 (CET) From: Jim Meyering To: Paul Eggert Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <4F26D770.8000207@cs.ucla.edu> (Paul Eggert's message of "Mon, 30 Jan 2012 09:46:24 -0800") References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> <4F04D82C.2070508@cs.ucla.edu> <87obtmnqi6.fsf@rho.meyering.net> <4F25C2B8.3070000@draigBrady.com> <87mx95mn8j.fsf@rho.meyering.net> <4F26D770.8000207@cs.ucla.edu> Date: Mon, 30 Jan 2012 20:42:31 +0100 Message-ID: <878vkpkme0.fsf@rho.meyering.net> Lines: 68 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, =?iso-8859-1?Q?P=E1draig?= Brady , Anders Kaseorg 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 (-) Paul Eggert wrote: > On 01/30/2012 03:41 AM, Jim Meyering wrote: >> /* At this point, it is normally an error (data loss) to move a symlink >> onto its referent, but in at least one narrow case, it is not: >> In move mode, when >> 1) src is a symlink, >> 2) dest is not a symlink, >> 3) dest has a link count of 2 or more and >> 4) dest and the referent of src are not the same entry, >> then it's ok, since while we'll lose one of those hard links, >> src will still point to a remaining link. >> Note that technically, condition #4 obviates condition #2, but we >> retain the 1 < st_nlink condition because that means fewer invocations >> of the more expensive #4. > > The last 3 lines are confusing. > Don't you mean "condition #3" and not "condition #2"? Good catch. You're right. > The last 2 lines talk about condition 3, not condition 2. > > Come to think of it, why is condition 2 needed at all? Another good catch. It's not needed. > Can't we eliminate it, both in the commentary and in the code? > If a symlink has a link count greater than 1, then overwriting > it won't lose the link; in that sense it's just like a regular > file with a link count greater than 1. So why are symlinks > special there? Thanks for the review! Adjusted via this: diff --git a/src/copy.c b/src/copy.c index 2c7582f..d66b0fc 100644 --- a/src/copy.c +++ b/src/copy.c @@ -1354,14 +1354,13 @@ same_file_ok (char const *src_name, struct stat const *src_sb, onto its referent, but in at least one narrow case, it is not: In move mode, when 1) src is a symlink, - 2) dest is not a symlink, - 3) dest has a link count of 2 or more and - 4) dest and the referent of src are not the same entry, + 2) dest has a link count of 2 or more and + 3) dest and the referent of src are not the same directory entry, then it's ok, since while we'll lose one of those hard links, src will still point to a remaining link. - Note that technically, condition #4 obviates condition #2, but we + Note that technically, condition #3 obviates condition #2, but we retain the 1 < st_nlink condition because that means fewer invocations - of the more expensive #4. + of the more expensive #3. Given this, $ touch f && ln f l && ln -s f s @@ -1373,7 +1372,6 @@ same_file_ok (char const *src_name, struct stat const *src_sb, this must succeed: mv s l */ if (x->move_mode && S_ISLNK (src_sb->st_mode) - && ! S_ISLNK (dst_sb->st_mode) && 1 < dst_sb_link->st_nlink) { char *abs_src = canonicalize_file_name (src_name); From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 31 07:35:46 2012 Received: (at 6960) by debbugs.gnu.org; 31 Jan 2012 12:35:46 +0000 Received: from localhost ([127.0.0.1]:46505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsCw6-0006tr-1O for submit@debbugs.gnu.org; Tue, 31 Jan 2012 07:35:46 -0500 Received: from mx.meyering.net ([88.168.87.75]:52322) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RsCw4-0006tg-AU for 6960@debbugs.gnu.org; Tue, 31 Jan 2012 07:35:45 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 2D95E60096; Tue, 31 Jan 2012 13:35:25 +0100 (CET) From: Jim Meyering To: Paul Eggert Subject: Re: bug#6960: mv refuses to move a symlink over a hard link to the same file In-Reply-To: <878vkpkme0.fsf@rho.meyering.net> (Jim Meyering's message of "Mon, 30 Jan 2012 20:42:31 +0100") References: <1283289668.1923.79.camel@mattlaptop2.local> <87obujayo7.fsf@rho.meyering.net> <4F04D82C.2070508@cs.ucla.edu> <87obtmnqi6.fsf@rho.meyering.net> <4F25C2B8.3070000@draigBrady.com> <87mx95mn8j.fsf@rho.meyering.net> <4F26D770.8000207@cs.ucla.edu> <878vkpkme0.fsf@rho.meyering.net> Date: Tue, 31 Jan 2012 13:35:25 +0100 Message-ID: <878vkohwxe.fsf@rho.meyering.net> Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 6960 Cc: 6960@debbugs.gnu.org, =?iso-8859-1?Q?P=E1draig?= Brady , Anders Kaseorg 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: ... > Thanks for the review! I've pushed that fix: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=d1b0155d805ce and am marking this "done". I've created a new ticket for the task of making 'mv --backup=numbered ...' atomic: http://bugs.gnu.org/10679 From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 13:57:19 2012 Received: (at control) by debbugs.gnu.org; 18 Feb 2012 18:57:19 +0000 Received: from localhost ([127.0.0.1]:44918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RypTC-0004Yj-Ja for submit@debbugs.gnu.org; Sat, 18 Feb 2012 13:57:19 -0500 Received: from mx.meyering.net ([88.168.87.75]:33563) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RypT9-0004Yb-N1 for control@debbugs.gnu.org; Sat, 18 Feb 2012 13:57:16 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id D58EF60061 for ; Sat, 18 Feb 2012 19:55:13 +0100 (CET) From: Jim Meyering To: control@debbugs.gnu.org Subject: really marking as done, now Date: Sat, 18 Feb 2012 19:55:13 +0100 Message-ID: <87zkcgdl9q.fsf@rho.meyering.net> Lines: 2 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: control 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 (-) close 6960 thanks From unknown Thu Sep 11 02:24:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 18 Mar 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator