From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 11:17:51 2013 Received: (at submit) by debbugs.gnu.org; 1 Apr 2013 15:17:51 +0000 Received: from localhost ([127.0.0.1]:56086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMgUY-0006Pt-NY for submit@debbugs.gnu.org; Mon, 01 Apr 2013 11:17:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57846) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMfyj-0005du-6q for submit@debbugs.gnu.org; Mon, 01 Apr 2013 10:44:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMfvo-0002fg-NR for submit@debbugs.gnu.org; Mon, 01 Apr 2013 10:42:04 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:47692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMfvo-0002fc-KZ for submit@debbugs.gnu.org; Mon, 01 Apr 2013 10:41:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMfvh-0003Kp-0U for bug-coreutils@gnu.org; Mon, 01 Apr 2013 10:41:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMfvY-0002b7-Lg for bug-coreutils@gnu.org; Mon, 01 Apr 2013 10:41:48 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:43044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMfvY-0002as-Gb for bug-coreutils@gnu.org; Mon, 01 Apr 2013 10:41:40 -0400 Received: by mail-pa0-f41.google.com with SMTP id kx1so1359500pab.28 for ; Mon, 01 Apr 2013 07:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=plPJNxYtesGQO00krmca3Wth+5kye0njGPFPSdhGvms=; b=lCMCMlP51N3bFWZYP2o+G+YdkFmqhrengN4opKV/rWS3xt7m9kgV/jq+4xCqi6sztN VnZ2NX4KMslNYvOfmTdod1sEeEYCQ0GMxtk1tsLpaloNnrR+++ZdAtCihJF1AS7o+PEw e+zM9aJVdw4KTPaj1o+SJqABJj1U8wOI7w2EM9DonO2cxyXNO5WK3oBXUngAy4mtS3Jp rIs7CQe5Z5NfxDpsDZW47P9AZ5FWr9XegdD/YyN9CsP1RoabSBEbZ9AuoEkTHQo0kfGP 1gUG/EQHPuPJef0oTE/7MuqyqD2CXzUj68kgaTNM0PI3Y59lHCMHBw7n8nxLALMeO9mg c6xQ== X-Received: by 10.66.121.202 with SMTP id lm10mr18990926pab.138.1364827299188; Mon, 01 Apr 2013 07:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.201 with HTTP; Mon, 1 Apr 2013 07:40:59 -0700 (PDT) From: =?ISO-8859-1?Q?R=E9my_Lefevre?= Date: Mon, 1 Apr 2013 16:40:59 +0200 Message-ID: Subject: [PATCH] ln: allow to overwrite relative symlink To: bug-coreutils@gnu.org Content-Type: multipart/mixed; boundary=047d7b41b7ec5915ce04d94d9eec X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 01 Apr 2013 11:17:48 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) --047d7b41b7ec5915ce04d94d9eec Content-Type: multipart/alternative; boundary=047d7b41b7ec5915ca04d94d9ee9 --047d7b41b7ec5915ca04d94d9ee9 Content-Type: text/plain; charset=ISO-8859-1 Overwriting relative symlink leads to undesirable behavior. Consider the following example: # Create some directories mkdir test mkdir test/folder1 mkdir test/folder2 #Create some files touch test/folder1/file1 touch test/folder1/file2 #Create a relative symlink in folder2 to file1 ln -sr test/folder1/file1 test/folder2/link #Check the link ls -l test/folder2/link # Correctly output a link to ../folder1/file1 #Overwrite the symlink to point to file2 ln -sfr test/folder1/file2 test/folder2/link #Check the link ls -l test/folder2/link # Wrongly output a link to file2 instead of ../folder1/file2 This undesirable behavior is due to a dereferencing of the target when the relative path is computed. Passing CAN_NOLINKS flag to canonicalize_filename_mode solves the problem. --047d7b41b7ec5915ca04d94d9ee9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Overwriting relative symlink leads to = undesirable behavior. Consider the following example:

# C= reate some directories
mkdir test
mkdir test/folder1
mkdir test/folder2

#Create some files
touch test= /folder1/file1
touch test/folder1/file2

#Cr= eate a relative symlink in folder2 to file1
ln -sr test/folde= r1/file1 test/folder2/link

#Check the link
ls -l test/folder2/link
# Correctly output a link to ../folder1/file1

#Overwrite the symlink to point to file2
ln -sfr test/folder1/file2 test/folder2/link

#Check the li= nk
ls -l test/folder2/link
# Wrongly output a link t= o file2 instead of ../folder1/file2


This undesirable = behavior is due to a dereferencing of the target when the relative path is = computed. Passing CAN_NOLINKS flag to canonicalize_filename_mode solves the= problem.
--047d7b41b7ec5915ca04d94d9ee9-- --047d7b41b7ec5915ce04d94d9eec Content-Type: application/octet-stream; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hezqxon70 ZGlmZiAtLWdpdCBhL3NyYy9sbi5jIGIvc3JjL2xuLmMKaW5kZXggMWFhMTQ3My4uYzkxODkyYiAx MDA2NDQKLS0tIGEvc3JjL2xuLmMKKysrIGIvc3JjL2xuLmMKQEAgLTEzMiw3ICsxMzIsOCBAQCB0 YXJnZXRfZGlyZWN0b3J5X29wZXJhbmQgKGNoYXIgY29uc3QgKmZpbGUpCiBzdGF0aWMgY2hhciAq CiBjb252ZXJ0X2Fic19yZWwgKGNvbnN0IGNoYXIgKmZyb20sIGNvbnN0IGNoYXIgKnRhcmdldCkK IHsKLSAgY2hhciAqcmVhbHRhcmdldCA9IGNhbm9uaWNhbGl6ZV9maWxlbmFtZV9tb2RlICh0YXJn ZXQsIENBTl9NSVNTSU5HKTsKKyAgY2hhciAqcmVhbHRhcmdldCA9IGNhbm9uaWNhbGl6ZV9maWxl bmFtZV9tb2RlICh0YXJnZXQsIAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENBTl9NSVNTSU5HIHwgQ0FOX05PTElOS1MpOwogICBjaGFyICpyZWFsZnJv bSA9IGNhbm9uaWNhbGl6ZV9maWxlbmFtZV9tb2RlIChmcm9tLCBDQU5fTUlTU0lORyk7CiAKICAg LyogV3JpdGUgdG8gYSBQQVRIX01BWCBidWZmZXIuICAqLwo= --047d7b41b7ec5915ce04d94d9eec-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 13:48:01 2013 Received: (at 14116) by debbugs.gnu.org; 1 Apr 2013 17:48:02 +0000 Received: from localhost ([127.0.0.1]:56288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMipr-0002UB-6p for submit@debbugs.gnu.org; Mon, 01 Apr 2013 13:48:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5947) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMipo-0002U3-58 for 14116@debbugs.gnu.org; Mon, 01 Apr 2013 13:47:57 -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 r31Hj1GU009530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Apr 2013 13:45:01 -0400 Received: from [10.36.116.44] (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r31HiwxU017199 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Apr 2013 13:45:00 -0400 Message-ID: <5159C799.1060903@draigBrady.com> Date: Mon, 01 Apr 2013 18:44:57 +0100 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9my_Lefevre?= Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id r31Hj1GU009530 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 14116 Cc: 14116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) On 04/01/2013 03:40 PM, R=E9my Lefevre wrote: > Overwriting relative symlink leads to undesirable behavior. Consider th= e > following example: >=20 > # Create some directories > mkdir test > mkdir test/folder1 > mkdir test/folder2 >=20 > #Create some files > touch test/folder1/file1 > touch test/folder1/file2 >=20 > #Create a relative symlink in folder2 to file1 > ln -sr test/folder1/file1 test/folder2/link >=20 > #Check the link > ls -l test/folder2/link > # Correctly output a link to ../folder1/file1 >=20 > #Overwrite the symlink to point to file2 > ln -sfr test/folder1/file2 test/folder2/link >=20 > #Check the link > ls -l test/folder2/link > # Wrongly output a link to file2 instead of ../folder1/file2 >=20 >=20 > This undesirable behavior is due to a dereferencing of the target when = the > relative path is computed. Passing CAN_NOLINKS flag to > canonicalize_filename_mode solves the problem. Doing that though breaks `ln -sr target1 target2 dir` where dir is a syml= ink. Also if /some/other/component of the path is a symlink, you probably want that resolved? You might even want the final component of the link name resolved in some cases. So perhaps the approach here is to only disable dereferencing when -n is set, and even then only for the last_component()= ? In other words, `ln -nsf ...` means update the specified link name no mat= ter what it is. -n used only be significant when the link name was to a directory, but with -r it's also significant if linking outside its containing direc= tory. I'll sort out a patch later. thanks, P=E1draig. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 16:14:04 2013 Received: (at 14116) by debbugs.gnu.org; 1 Apr 2013 20:14:05 +0000 Received: from localhost ([127.0.0.1]:56484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMl7E-00071A-DB for submit@debbugs.gnu.org; Mon, 01 Apr 2013 16:14:04 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:64286) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMl7A-00070c-WD for 14116@debbugs.gnu.org; Mon, 01 Apr 2013 16:14:02 -0400 Received: by mail-pa0-f49.google.com with SMTP id kp14so1469233pab.22 for <14116@debbugs.gnu.org>; Mon, 01 Apr 2013 13:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=DizJ2E/SsrAmJSTrWBx7wpSU/Tr4WYY3LREWvjqfRnQ=; b=qBy/CraN/HAzcnA4chC6Iok8aJEUpz/V1/UO2XSC38zIUZcuCEMEYHViIDi8p3tX2T xnDV+SFbPM4LsdeUDJvrGZcSJfwDmStv3tBuVqtRAHBzXgpDAx4Xo4CKlo2hud1HylBT fsDPsCDlOyMgy9W/23pBtBJFhzeBbT1xtZ27m041gYnshOufmSvbX9MYmznmmKgw8kHz WhLyIOza02+Wu5kv4ktBascMrUrTyD1a0/uWOLW5GpptPIR/2XCS3o3QjGWARITday4I 73VmnC7tnz+syRhghpl0Td9pbqrorOxDg0Q2ipt63p9SP03o30sxeiec1j2hpZCrorJP pA8Q== X-Received: by 10.66.255.41 with SMTP id an9mr20578448pad.44.1364847065616; Mon, 01 Apr 2013 13:11:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.201 with HTTP; Mon, 1 Apr 2013 13:10:25 -0700 (PDT) In-Reply-To: <5159C799.1060903@draigBrady.com> References: <5159C799.1060903@draigBrady.com> From: =?ISO-8859-1?Q?R=E9my_Lefevre?= Date: Mon, 1 Apr 2013 22:10:25 +0200 Message-ID: Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink To: =?ISO-8859-1?Q?P=E1draig_Brady?= Content-Type: multipart/alternative; boundary=047d7b15accf84d72504d9523809 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 14116 Cc: 14116@debbugs.gnu.org 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: -2.6 (--) --047d7b15accf84d72504d9523809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You are right. It breaks any path composed of link. Sorry for this bad patch. But could you provide me an example where the final component of the link should be resolved ? Does it make sense as the link will be overwritten? I must be missing something. R=E9my. 2013/4/1 P=E1draig Brady > On 04/01/2013 03:40 PM, R=E9my Lefevre wrote: > > Overwriting relative symlink leads to undesirable behavior. Consider th= e > > following example: > > > > # Create some directories > > mkdir test > > mkdir test/folder1 > > mkdir test/folder2 > > > > #Create some files > > touch test/folder1/file1 > > touch test/folder1/file2 > > > > #Create a relative symlink in folder2 to file1 > > ln -sr test/folder1/file1 test/folder2/link > > > > #Check the link > > ls -l test/folder2/link > > # Correctly output a link to ../folder1/file1 > > > > #Overwrite the symlink to point to file2 > > ln -sfr test/folder1/file2 test/folder2/link > > > > #Check the link > > ls -l test/folder2/link > > # Wrongly output a link to file2 instead of ../folder1/file2 > > > > > > This undesirable behavior is due to a dereferencing of the target when > the > > relative path is computed. Passing CAN_NOLINKS flag to > > canonicalize_filename_mode solves the problem. > > Doing that though breaks `ln -sr target1 target2 dir` where dir is a > symlink. > Also if /some/other/component of the path is a symlink, you probably want > that resolved? You might even want the final component of the link name > resolved in some cases. So perhaps the approach here is to only disable > dereferencing when -n is set, and even then only for the last_component()= ? > > In other words, `ln -nsf ...` means update the specified link name no > matter what it is. > -n used only be significant when the link name was to a directory, > but with -r it's also significant if linking outside its containing > directory. > > I'll sort out a patch later. > > thanks, > P=E1draig. > --047d7b15accf84d72504d9523809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You are right. It breaks any path composed of link. S= orry for this bad patch.

But could you provide me an example where t= he final component of the link should be resolved ? Does it make sense as t= he link will be overwritten? I must be missing something.

R=E9my.


2013/4/1 P=E1draig Brady <P@draigbrady.com>=
On 04/01/2013 03:40 PM, R=E9my Lefevre wrote:
> Overwriting relative symlink leads to undesirable behavior. Consider t= he
> following example:
>
> # Create some directories
> mkdir test
> mkdir test/folder1
> mkdir test/folder2
>
> #Create some files
> touch test/folder1/file1
> touch test/folder1/file2
>
> #Create a relative symlink in folder2 to file1
> ln -sr test/folder1/file1 test/folder2/link
>
> #Check the link
> ls -l test/folder2/link
> # Correctly output a link to ../folder1/file1
>
> #Overwrite the symlink to point to file2
> ln -sfr test/folder1/file2 test/folder2/link
>
> #Check the link
> ls -l test/folder2/link
> # Wrongly output a link to file2 instead of ../folder1/file2
>
>
> This undesirable behavior is due to a dereferencing of the target when= the
> relative path is computed. Passing CAN_NOLINKS flag to
> canonicalize_filename_mode solves the problem.

Doing that though breaks `ln -sr target1 target2 dir` where dir is a symlin= k.
Also if /some/other/component of the path is a symlink, you probably want that resolved? You might even want the final component of the link name
resolved in some cases. So perhaps the approach here is to only disable
dereferencing when -n is set, and even then only for the last_component()?<= br>
In other words, `ln -nsf ...` means update the specified link name no matte= r what it is.
-n used only be significant when the link name was to a directory,
but with -r it's also significant if linking outside its containing dir= ectory.

I'll sort out a patch later.

thanks,
P=E1draig.

--047d7b15accf84d72504d9523809-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 20:19:15 2013 Received: (at 14116) by debbugs.gnu.org; 2 Apr 2013 00:19:15 +0000 Received: from localhost ([127.0.0.1]:56776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMowV-0004up-9i for submit@debbugs.gnu.org; Mon, 01 Apr 2013 20:19:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48429) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMowS-0004ug-1v for 14116@debbugs.gnu.org; Mon, 01 Apr 2013 20:19:13 -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 r320GFRT010471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Apr 2013 20:16:15 -0400 Received: from [10.36.116.44] (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r320GCvg030532 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Apr 2013 20:16:14 -0400 Message-ID: <515A234C.4040603@draigBrady.com> Date: Tue, 02 Apr 2013 01:16:12 +0100 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9my_Lefevre?= Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: <5159C799.1060903@draigBrady.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id r320GFRT010471 X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: 14116 Cc: 14116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) On 04/01/2013 09:10 PM, R=E9my Lefevre wrote: > R=E9my. >=20 >=20 > 2013/4/1 P=E1draig Brady > >=20 > On 04/01/2013 03:40 PM, R=E9my Lefevre wrote: > > Overwriting relative symlink leads to undesirable behavior. Consi= der the > > following example: > > > > # Create some directories > > mkdir test > > mkdir test/folder1 > > mkdir test/folder2 > > > > #Create some files > > touch test/folder1/file1 > > touch test/folder1/file2 > > > > #Create a relative symlink in folder2 to file1 > > ln -sr test/folder1/file1 test/folder2/link > > > > #Check the link > > ls -l test/folder2/link > > # Correctly output a link to ../folder1/file1 > > > > #Overwrite the symlink to point to file2 > > ln -sfr test/folder1/file2 test/folder2/link > > > > #Check the link > > ls -l test/folder2/link > > # Wrongly output a link to file2 instead of ../folder1/file2 > > > > > > This undesirable behavior is due to a dereferencing of the target= when the > > relative path is computed. Passing CAN_NOLINKS flag to > > canonicalize_filename_mode solves the problem. >=20 > Doing that though breaks `ln -sr target1 target2 dir` where dir is = a symlink. > Also if /some/other/component of the path is a symlink, you probabl= y want > that resolved? You might even want the final component of the link = name > resolved in some cases. So perhaps the approach here is to only dis= able > dereferencing when -n is set, and even then only for the last_compo= nent()? >=20 > In other words, `ln -nsf ...` means update the specified link name = no matter what it is. > -n used only be significant when the link name was to a directory, > but with -r it's also significant if linking outside its containing= directory. >=20 > I'll sort out a patch later. > > You are right. It breaks any path composed of link. Sorry for this bad = patch. >=20 > But could you provide me an example where the final component of the li= nk should be resolved ? Does it make sense as the link will be overwritte= n? I must be missing something. Yes resolving the last component would be a departure from existing behav= ior. So it there is no need to conditionalize this on -n, and we just need to resolve the path without the last_component() and then tack that on. thanks, P=E1draig. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 02 06:34:28 2013 Received: (at 14116) by debbugs.gnu.org; 2 Apr 2013 10:34:28 +0000 Received: from localhost ([127.0.0.1]:57318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMyXr-00043J-AQ for submit@debbugs.gnu.org; Tue, 02 Apr 2013 06:34:28 -0400 Received: from mail-pd0-f179.google.com ([209.85.192.179]:54744) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UMyXp-00043B-4w for 14116@debbugs.gnu.org; Tue, 02 Apr 2013 06:34:26 -0400 Received: by mail-pd0-f179.google.com with SMTP id x11so167243pdj.10 for <14116@debbugs.gnu.org>; Tue, 02 Apr 2013 03:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OgTKR5UrEAVXk7PDLtOb6V0UmaTpklVZNyHZMLaGMqU=; b=w+OkCtG2MFS5EIuoefXp/0dvvdNU9HYQiDIOKewq+Eb/6juUai4/iaoQQ4VAGewv9V /YBvqfBXrgoctbc63K5dzRR8Yh4FqHb/714NlijSP52GyGS95t9hUeJddvW5LgQecCR6 q+ikSWvGK0enxQX8J6YzBFCeeP3oQ6gm28IbQYdyMiku0z+pUCLsSjOvljtz1T+j20gO 0t7h3OeV/gBLLcUGGTlGCdbvrmtSSFCdNSPWR9mjYoFRQ5mhpxjhKX8vhNjOiA9amO58 fyU2Gw5I/yMmcVeFzq0x/RxeI62oLmQZgIwGft3yNU6rG386e3BNuiZvHLrtsl891V7z ZUGA== X-Received: by 10.68.243.66 with SMTP id ww2mr23308219pbc.109.1364898686633; Tue, 02 Apr 2013 03:31:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.201 with HTTP; Tue, 2 Apr 2013 03:30:46 -0700 (PDT) In-Reply-To: <515A234C.4040603@draigBrady.com> References: <5159C799.1060903@draigBrady.com> <515A234C.4040603@draigBrady.com> From: =?ISO-8859-1?Q?R=E9my_Lefevre?= Date: Tue, 2 Apr 2013 12:30:46 +0200 Message-ID: Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink To: =?ISO-8859-1?Q?P=E1draig_Brady?= Content-Type: multipart/mixed; boundary=e89a8f83a6b15f240304d95e3d6f X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 14116 Cc: 14116 <14116@debbugs.gnu.org> 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 (-) --e89a8f83a6b15f240304d95e3d6f Content-Type: multipart/alternative; boundary=e89a8f83a6b15f23ff04d95e3d6d --e89a8f83a6b15f23ff04d95e3d6d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not sure to understand your first sentence. Resolving the last component is already the existing behavior, but maybe not the intended one. Anyway, I agree that the path should be resolved without its last component= . I wrote a new patch for this. I hope that this one will not break anything. R=E9my. 2013/4/2 P=E1draig Brady > On 04/01/2013 09:10 PM, R=E9my Lefevre wrote: > > R=E9my. > > > > > > 2013/4/1 P=E1draig Brady > > > > > On 04/01/2013 03:40 PM, R=E9my Lefevre wrote: > > > Overwriting relative symlink leads to undesirable behavior. > Consider the > > > following example: > > > > > > # Create some directories > > > mkdir test > > > mkdir test/folder1 > > > mkdir test/folder2 > > > > > > #Create some files > > > touch test/folder1/file1 > > > touch test/folder1/file2 > > > > > > #Create a relative symlink in folder2 to file1 > > > ln -sr test/folder1/file1 test/folder2/link > > > > > > #Check the link > > > ls -l test/folder2/link > > > # Correctly output a link to ../folder1/file1 > > > > > > #Overwrite the symlink to point to file2 > > > ln -sfr test/folder1/file2 test/folder2/link > > > > > > #Check the link > > > ls -l test/folder2/link > > > # Wrongly output a link to file2 instead of ../folder1/file2 > > > > > > > > > This undesirable behavior is due to a dereferencing of the target > when the > > > relative path is computed. Passing CAN_NOLINKS flag to > > > canonicalize_filename_mode solves the problem. > > > > Doing that though breaks `ln -sr target1 target2 dir` where dir is = a > symlink. > > Also if /some/other/component of the path is a symlink, you probabl= y > want > > that resolved? You might even want the final component of the link > name > > resolved in some cases. So perhaps the approach here is to only > disable > > dereferencing when -n is set, and even then only for the > last_component()? > > > > In other words, `ln -nsf ...` means update the specified link name > no matter what it is. > > -n used only be significant when the link name was to a directory, > > but with -r it's also significant if linking outside its containing > directory. > > > > I'll sort out a patch later. > > > > You are right. It breaks any path composed of link. Sorry for this bad > patch. > > > > But could you provide me an example where the final component of the > link should be resolved ? Does it make sense as the link will be > overwritten? I must be missing something. > > Yes resolving the last component would be a departure from existing > behavior. > So it there is no need to conditionalize this on -n, and we just need > to resolve the path without the last_component() and then tack that on. > > thanks, > P=E1draig. > --e89a8f83a6b15f23ff04d95e3d6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not sure to understand your first senten= ce. Resolving the last component is already the existing behavior, but mayb= e not the intended one.

Anyway, I agree that the path should be reso= lved without its last component.

I wrote a new patch for this. I hope that this one will not break= anything.

R=E9my.

2013/4/2 P=E1draig Brady <= P@draigbrady.com&= gt;
On 04/01/2013 09:10 PM, R= =E9my Lefevre wrote:
> R=E9my.
>
>
> 2013/4/1 P=E1draig Brady <P@draigbrady.com <mailto:P@drai= gbrady.com>>
>
> =A0 =A0 On 04/01/2013 03:40 PM, R=E9my Lefevre wrote:
> =A0 =A0 > Overwriting relative symlink leads to undesirable behavio= r. Consider the
> =A0 =A0 > following example:
> =A0 =A0 >
> =A0 =A0 > # Create some directories
> =A0 =A0 > mkdir test
> =A0 =A0 > mkdir test/folder1
> =A0 =A0 > mkdir test/folder2
> =A0 =A0 >
> =A0 =A0 > #Create some files
> =A0 =A0 > touch test/folder1/file1
> =A0 =A0 > touch test/folder1/file2
> =A0 =A0 >
> =A0 =A0 > #Create a relative symlink in folder2 to file1
> =A0 =A0 > ln -sr test/folder1/file1 test/folder2/link
> =A0 =A0 >
> =A0 =A0 > #Check the link
> =A0 =A0 > ls -l test/folder2/link
> =A0 =A0 > # Correctly output a link to ../folder1/file1
> =A0 =A0 >
> =A0 =A0 > #Overwrite the symlink to point to file2
> =A0 =A0 > ln -sfr test/folder1/file2 test/folder2/link
> =A0 =A0 >
> =A0 =A0 > #Check the link
> =A0 =A0 > ls -l test/folder2/link
> =A0 =A0 > # Wrongly output a link to file2 instead of ../folder1/fi= le2
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > This undesirable behavior is due to a dereferencing of th= e target when the
> =A0 =A0 > relative path is computed. Passing CAN_NOLINKS flag to > =A0 =A0 > canonicalize_filename_mode solves the problem.
>
> =A0 =A0 Doing that though breaks `ln -sr target1 target2 dir` where di= r is a symlink.
> =A0 =A0 Also if /some/other/component of the path is a symlink, you pr= obably want
> =A0 =A0 that resolved? You might even want the final component of the = link name
> =A0 =A0 resolved in some cases. So perhaps the approach here is to onl= y disable
> =A0 =A0 dereferencing when -n is set, and even then only for the last_= component()?
>
> =A0 =A0 In other words, `ln -nsf ...` means update the specified link = name no matter what it is.
> =A0 =A0 -n used only be significant when the link name was to a direct= ory,
> =A0 =A0 but with -r it's also significant if linking outside its c= ontaining directory.
>
> =A0 =A0 I'll sort out a patch later.
>
> You are right. It breaks any path compos= ed of link. Sorry for this bad patch.
>
> But could you provide me an example where the final component of the l= ink should be resolved ? Does it make sense as the link will be overwritten= ? I must be missing something.

Yes resolving the last component would be a departure from existing b= ehavior.
So it there is no need to conditionalize this on -n, and we just need
to resolve the path without the last_component() and then tack that on.

thanks,
P=E1draig.

--e89a8f83a6b15f23ff04d95e3d6d-- --e89a8f83a6b15f240304d95e3d6f Content-Type: application/octet-stream; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hf0xfseb0 ZGlmZiAtLWdpdCBhL3NyYy9sbi5jIGIvc3JjL2xuLmMKaW5kZXggMWFhMTQ3My4uMTM1MzdhYyAx MDA2NDQKLS0tIGEvc3JjL2xuLmMKKysrIGIvc3JjL2xuLmMKQEAgLTEzMiwyMSArMTMyLDIzIEBA IHRhcmdldF9kaXJlY3Rvcnlfb3BlcmFuZCAoY2hhciBjb25zdCAqZmlsZSkKIHN0YXRpYyBjaGFy ICoKIGNvbnZlcnRfYWJzX3JlbCAoY29uc3QgY2hhciAqZnJvbSwgY29uc3QgY2hhciAqdGFyZ2V0 KQogewotICBjaGFyICpyZWFsdGFyZ2V0ID0gY2Fub25pY2FsaXplX2ZpbGVuYW1lX21vZGUgKHRh cmdldCwgQ0FOX01JU1NJTkcpOworICAvKiBHZXQgZGlybmFtZSB0byBnZW5lcmF0ZSBwYXRocyBy ZWxhdGl2ZSB0bworICAgICBhbmQgdG8gbm90IHJlc29sdmUgdGhlIGxhc3QgY29tcG9uZW50IG9m IHRhcmdldC4gICovCisgIGNoYXIgKnRhcmdldGRpciA9IGRpcl9uYW1lICh0YXJnZXQpOworCisg IGNoYXIgKnJlYWx0YXJnZXQgPSBjYW5vbmljYWxpemVfZmlsZW5hbWVfbW9kZSAodGFyZ2V0ZGly LCBDQU5fTUlTU0lORyk7CiAgIGNoYXIgKnJlYWxmcm9tID0gY2Fub25pY2FsaXplX2ZpbGVuYW1l X21vZGUgKGZyb20sIENBTl9NSVNTSU5HKTsKIAogICAvKiBXcml0ZSB0byBhIFBBVEhfTUFYIGJ1 ZmZlci4gICovCiAgIGNoYXIgKnJlbGF0aXZlX2Zyb20gPSB4bWFsbG9jIChQQVRIX01BWCk7CiAK LSAgLyogR2V0IGRpcm5hbWUgdG8gZ2VuZXJhdGUgcGF0aHMgcmVsYXRpdmUgdG8uICAqLwotICBy ZWFsdGFyZ2V0W2Rpcl9sZW4gKHJlYWx0YXJnZXQpXSA9ICdcMCc7Ci0KICAgaWYgKCFyZWxwYXRo IChyZWFsZnJvbSwgcmVhbHRhcmdldCwgcmVsYXRpdmVfZnJvbSwgUEFUSF9NQVgpKQogICAgIHsK ICAgICAgIGZyZWUgKHJlbGF0aXZlX2Zyb20pOwogICAgICAgcmVsYXRpdmVfZnJvbSA9IE5VTEw7 CiAgICAgfQogCisgIGZyZWUgKHRhcmdldGRpcik7CiAgIGZyZWUgKHJlYWx0YXJnZXQpOwogICBm cmVlIChyZWFsZnJvbSk7CiAK --e89a8f83a6b15f240304d95e3d6f-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 03 13:47:06 2013 Received: (at 14116-done) by debbugs.gnu.org; 3 Apr 2013 17:47:07 +0000 Received: from localhost ([127.0.0.1]:60371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNRm6-0007on-Af for submit@debbugs.gnu.org; Wed, 03 Apr 2013 13:47:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39097) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNRm3-0007oP-A7 for 14116-done@debbugs.gnu.org; Wed, 03 Apr 2013 13:47:05 -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 r33Hhulu031861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Apr 2013 13:43:56 -0400 Received: from [10.36.116.21] (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r33Hhrr5031789 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 13:43:55 -0400 Message-ID: <515C6A59.7060803@draigBrady.com> Date: Wed, 03 Apr 2013 18:43:53 +0100 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9my_Lefevre?= Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: <5159C799.1060903@draigBrady.com> <515A234C.4040603@draigBrady.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/mixed; boundary="------------080706030605050207000505" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 14116-done Cc: 14116-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) This is a multi-part message in MIME format. --------------080706030605050207000505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id r33Hhulu031861 On 04/02/2013 11:30 AM, R=E9my Lefevre wrote: > I'm not sure to understand your first sentence. Resolving the last comp= onent is already the existing behavior, but maybe not the intended one. >=20 > Anyway, I agree that the path should be resolved without its last compo= nent. >=20 > I wrote a new patch for this. I hope that this one will not break anyth= ing. It looks good. I've attached the full patch in your name with a test and NEWS entry. Also attached is a related doc change, detailing the symlink resolution done with ln --relative. thanks! P=E1draig. --------------080706030605050207000505 Content-Type: text/x-patch; name="ln--relative--symlink.patch" Content-Disposition: attachment; filename="ln--relative--symlink.patch" Content-Transfer-Encoding: 7bit >From 926cc41a37e89e34c17e7299cd70aea66f9ae280 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Lefevre?= Date: Tue, 2 Apr 2013 02:48:28 +0100 Subject: [PATCH 1/2] ln: --relative: fix updating of existing symlinks Don't dereference an existing symlink being replaced. I.E. generate the symlink relative to the symlink's containing dir, rather than to some arbitrary place it points to. * src/ln.c (convert_abs_rel): Don't consider the final component of the symlink name when canonicalizing, as we to avoid dreferencing the final component. * tests/ln/relative.sh: Add a test case. * NEWS: Mention the fix. --- NEWS | 4 ++++ src/ln.c | 14 ++++++++------ tests/ln/relative.sh | 5 +++++ 3 files changed, 17 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 0c2daad..b9fc6d2 100644 --- a/NEWS +++ b/NEWS @@ -9,6 +9,10 @@ GNU coreutils NEWS -*- outline -*- permissions. [This bug was present in "the beginning".] + ln --relative now updates existing symlinks correctly. Previously it based + the relative link on the dereferenced path of an existing link. + [This bug was introduced when --relative was added in coreutils-8.16.] + ** New features join accepts a new option: --zero-terminated (-z). As with the sort,uniq diff --git a/src/ln.c b/src/ln.c index 1aa1473..2489b9a 100644 --- a/src/ln.c +++ b/src/ln.c @@ -132,22 +132,24 @@ target_directory_operand (char const *file) static char * convert_abs_rel (const char *from, const char *target) { - char *realtarget = canonicalize_filename_mode (target, CAN_MISSING); + /* Get dirname to generate paths relative to. We don't resolve + the full TARGET as the last component could be an existing symlink. */ + char *targetdir = dir_name (target); + + char *realdest = canonicalize_filename_mode (targetdir, CAN_MISSING); char *realfrom = canonicalize_filename_mode (from, CAN_MISSING); /* Write to a PATH_MAX buffer. */ char *relative_from = xmalloc (PATH_MAX); - /* Get dirname to generate paths relative to. */ - realtarget[dir_len (realtarget)] = '\0'; - - if (!relpath (realfrom, realtarget, relative_from, PATH_MAX)) + if (!relpath (realfrom, realdest, relative_from, PATH_MAX)) { free (relative_from); relative_from = NULL; } - free (realtarget); + free (targetdir); + free (realdest); free (realfrom); return relative_from ? relative_from : xstrdup (from); diff --git a/tests/ln/relative.sh b/tests/ln/relative.sh index 0418b8a..818da83 100755 --- a/tests/ln/relative.sh +++ b/tests/ln/relative.sh @@ -29,4 +29,9 @@ test $(readlink usr/bin/foo) = '../lib/foo/foo' || fail=1 ln -sr usr/bin/foo usr/lib/foo/link-to-foo test $(readlink usr/lib/foo/link-to-foo) = 'foo' || fail=1 +# Correctly update an existing link, which was broken in <= 8.21 +ln -s dir1/dir2/f existing_link +ln -srf here existing_link +test $(readlink existing_link) = 'here' || fail=1 + Exit $fail -- 1.7.7.6 >From c5dc794a2723656b1943e7c9f52f91ea2b4b55fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Wed, 3 Apr 2013 18:33:43 +0100 Subject: [PATCH 2/2] doc: add details on ln --relative symlink resolution * doc/coreutils.texi (ln invocation): Describe how symlinks are resolved with --relative, and give an example showing the greater control available through realpath(1). * tests/ln/relative.sh: Add a test to demonstrate full symlink resolution, in a case where it might not be wanted. --- doc/coreutils.texi | 18 +++++++++++++++++- tests/ln/relative.sh | 11 +++++++++++ 2 files changed, 28 insertions(+), 1 deletions(-) diff --git a/doc/coreutils.texi b/doc/coreutils.texi index dfa9b1c..4cfe4c5 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -9798,8 +9798,24 @@ ln -srv /a/file /tmp '/tmp/file' -> '../a/file' @end smallexample +Relative symbolic links are generated based on their canonicalized +containing directory, and canonicalized targets. I.E. all symbolic +links in these file names will be resolved. @xref{realpath invocation}, which gives greater control -over relative file name generation. +over relative file name generation, as demonstrated in the following example: + +@example +@verbatim +ln--relative() { + test "$1" = --no-symlinks && { nosym=$1; shift; } + target="$1"; + test -d "$2" && link="$2/." || link="$2" + rtarget="$(realpath $nosym -m "$target" \ + --relative-to "$(dirname "$link")")" + ln -s -v "$rtarget" "$link" +} +@end verbatim +@end example @item -s @itemx --symbolic diff --git a/tests/ln/relative.sh b/tests/ln/relative.sh index 818da83..bbe7db7 100755 --- a/tests/ln/relative.sh +++ b/tests/ln/relative.sh @@ -34,4 +34,15 @@ ln -s dir1/dir2/f existing_link ln -srf here existing_link test $(readlink existing_link) = 'here' || fail=1 +# Demonstrate resolved symlinks used to generate relative links +# so here,'web/latest' will not be linked to the intermediate 'latest' link. +# You'd probably want to use realpath(1) in conjunction +# with ln(1) without --relative to give greater control. +ln -s release1 alpha +ln -s release2 beta +ln -s beta latest +mkdir web +ln -sr latest web/latest +test $(readlink web/latest) = '../release2' || fail=1 + Exit $fail -- 1.7.7.6 --------------080706030605050207000505-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 03 19:09:42 2013 Received: (at 14116) by debbugs.gnu.org; 3 Apr 2013 23:09:42 +0000 Received: from localhost ([127.0.0.1]:60726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNWoH-00011H-S5 for submit@debbugs.gnu.org; Wed, 03 Apr 2013 19:09:42 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:58393) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNWoF-000118-Gu for 14116@debbugs.gnu.org; Wed, 03 Apr 2013 19:09:40 -0400 Received: from [192.168.1.11] (p5091FFFA.dip.t-dialin.net [80.145.255.250]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LzneB-1UkEMg0unr-0153zr; Thu, 04 Apr 2013 01:06:29 +0200 Message-ID: <515CB5F4.8050605@bernhard-voelker.de> Date: Thu, 04 Apr 2013 01:06:28 +0200 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: 14116@debbugs.gnu.org, P@draigBrady.com, lefevreremy@gmail.com Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: <5159C799.1060903@draigBrady.com> <515A234C.4040603@draigBrady.com> <515C6A59.7060803@draigBrady.com> In-Reply-To: <515C6A59.7060803@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:8/xW5XwxDkhtK/IjPD9rGAFsjKEZgYHB9s/uDjHnnI/ 3WSgvZ929OmUzvZue+5sRMZEHxllrHoRV01ZDnEVMqBW6Rpjvm vdK5RvnWLH5pyD4jieeJFOZEjlmqvp1rJpWaneMfv2vpZlvw+m h1qSlTXdlWbVjRct4BBGU7zNlETb5mq0CZcHpu2JhjapMc7Fuo iYbaWBap3TU/dCfq98YP++W4d4+P2fPEeXmqHe9rUN8qctFfwd D0mNfbAhVWHXbEk1u/lATk5FWrJYarCdYjmjYwCV39oV3qQytw yKjhojGqC0NPuu69HaDcc+2K/KgbjPW+c08U9XCx6R0oz9Md8R bEg1C19CPkNKL+T3E4bRTGA5VOIHwHEactry8jWny X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 14116 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 04/03/2013 07:43 PM, Pádraig Brady wrote: > Subject: [PATCH 1/2] ln: --relative: fix updating of existing symlinks > > Don't dereference an existing symlink being replaced. > I.E. generate the symlink relative to the symlink's containing dir, > rather than to some arbitrary place it points to. > > * src/ln.c (convert_abs_rel): Don't consider the final component > of the symlink name when canonicalizing, as we to avoid s/as we to/as to/ ? > dreferencing the final component. s/dreferencing/dereferencing/ BTW: the commit message should reference this bug: http://bugs.gnu.org/14116 > Subject: [PATCH 2/2] doc: add details on ln --relative symlink resolution > [...] > @@ -34,4 +34,15 @@ ln -s dir1/dir2/f existing_link > ln -srf here existing_link > test $(readlink existing_link) = 'here' || fail=1 > > +# Demonstrate resolved symlinks used to generate relative links > +# so here,'web/latest' will not be linked to the intermediate 'latest' link. s/,/, / Apart from the above nits, the 2 patches look good. Have a nice day, Berny From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 03 21:51:40 2013 Received: (at 14116) by debbugs.gnu.org; 4 Apr 2013 01:51:40 +0000 Received: from localhost ([127.0.0.1]:60864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNZL1-0005JA-HB for submit@debbugs.gnu.org; Wed, 03 Apr 2013 21:51:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61783) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNZKx-0005J0-P8 for 14116@debbugs.gnu.org; Wed, 03 Apr 2013 21:51:37 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r341mPPI015276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Apr 2013 21:48:25 -0400 Received: from [10.36.116.21] (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r341mMg5027872 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 21:48:24 -0400 Message-ID: <515CDBE6.8070109@draigBrady.com> Date: Thu, 04 Apr 2013 02:48:22 +0100 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bernhard Voelker Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: <5159C799.1060903@draigBrady.com> <515A234C.4040603@draigBrady.com> <515C6A59.7060803@draigBrady.com> <515CB5F4.8050605@bernhard-voelker.de> In-Reply-To: <515CB5F4.8050605@bernhard-voelker.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id r341mPPI015276 X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: 14116 Cc: lefevreremy@gmail.com, 14116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) On 04/04/2013 12:06 AM, Bernhard Voelker wrote: > On 04/03/2013 07:43 PM, P=E1draig Brady wrote: >=20 >> Subject: [PATCH 1/2] ln: --relative: fix updating of existing symlinks >> >> Don't dereference an existing symlink being replaced. >> I.E. generate the symlink relative to the symlink's containing dir, >> rather than to some arbitrary place it points to. >> >> * src/ln.c (convert_abs_rel): Don't consider the final component >> of the symlink name when canonicalizing, as we to avoid >=20 > s/as we to/as to/ ? >=20 >> dreferencing the final component. >=20 > s/dreferencing/dereferencing/ >=20 > BTW: the commit message should reference this bug: > http://bugs.gnu.org/14116 >=20 >> Subject: [PATCH 2/2] doc: add details on ln --relative symlink resolut= ion >> [...] >> @@ -34,4 +34,15 @@ ln -s dir1/dir2/f existing_link >> ln -srf here existing_link >> test $(readlink existing_link) =3D 'here' || fail=3D1 >> =20 >> +# Demonstrate resolved symlinks used to generate relative links >> +# so here,'web/latest' will not be linked to the intermediate 'latest= ' link. >=20 > s/,/, / >=20 > Apart from the above nits, the 2 patches look good. Thanks for the review! Pushed. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 03:24:36 2013 Received: (at 14116) by debbugs.gnu.org; 7 Apr 2013 07:24:36 +0000 Received: from localhost ([127.0.0.1]:37888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOjxm-0003FH-UG for submit@debbugs.gnu.org; Sun, 07 Apr 2013 03:24:36 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:41676 helo=Ishtar.hs.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOjxf-0003Ev-67 for 14116@debbugs.gnu.org; Sun, 07 Apr 2013 03:24:28 -0400 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.5/8.14.4/SuSE Linux 0.8) with ESMTP id r377KsId017696; Sun, 7 Apr 2013 00:20:56 -0700 Message-ID: <51611E53.2030401@tlinx.org> Date: Sun, 07 Apr 2013 00:20:51 -0700 From: Linda Walsh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Rémy Lefevre Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: <5159C799.1060903@draigBrady.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by Ishtar.hs.tlinx.org id r377KsId017696 X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 14116 Cc: 14116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) R=C3=A9my Lefevre wrote: [>> P=C3=A1draig Brady wrote: >> Doing that though breaks `ln -sr target1 target2 dir` where dir is a s= ymlink. ] > But could you provide me an example where the final component of the li= nk > should be resolved ? --- What happens if 'dir' is a symlink, "-n" is used, and '/' (or '/.') is appended to "dir" in the above example? Would that force 'dir' to be resolved, on the basis that '/' would be the final component. Some, might argue that it's a separato= r and not a component, but, historically, the three haven't given synonymous semantics. =09 From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 06:40:11 2013 Received: (at 14116) by debbugs.gnu.org; 7 Apr 2013 10:40:11 +0000 Received: from localhost ([127.0.0.1]:38011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOn19-0007qG-7B for submit@debbugs.gnu.org; Sun, 07 Apr 2013 06:40:11 -0400 Received: from mail3.vodafone.ie ([213.233.128.45]:10516) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOn0x-0007pd-LI for 14116@debbugs.gnu.org; Sun, 07 Apr 2013 06:40:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkDALhLYVFda1zH/2dsb2JhbAANRIZmuxmCYAMBgRaDEwEBAQQjDwFGEAsNAQoCAgUWCwICCQMCAQIBRQYNAQcBAbJ4cZFpgSONIV8Hgi6BEwOdGo10 Received: from unknown (HELO [192.168.1.79]) ([93.107.92.199]) by mail3.vodafone.ie with ESMTP; 07 Apr 2013 11:36:31 +0100 Message-ID: <51614C2F.7090307@draigBrady.com> Date: Sun, 07 Apr 2013 11:36:31 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Linda Walsh Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: <5159C799.1060903@draigBrady.com> <51611E53.2030401@tlinx.org> In-Reply-To: <51611E53.2030401@tlinx.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 14116 Cc: =?UTF-8?B?UsOpbXkgTGVmZXZyZQ==?= , 14116@debbugs.gnu.org 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 04/07/2013 08:20 AM, Linda Walsh wrote: > > > Rémy Lefevre wrote: > [>> Pádraig Brady wrote: >>> Doing that though breaks `ln -sr target1 target2 dir` where dir is a symlink. > ] >> But could you provide me an example where the final component of the link >> should be resolved ? > --- > What happens if 'dir' is a symlink, "-n" is used, and > '/' (or '/.') is appended to "dir" in the above example? > > Would that force 'dir' to be resolved, on the basis that > '/' would be the final component. Some, might argue that it's a separator > and not a component, but, historically, the three haven't given > synonymous semantics. Yes that does force 'dir' to be resolved, which is consistent with the non --relative case where the symlink is resolved to a dir when both -n and a trailing '/' are used. ln -sn target1 target2 dir/ thanks, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 10:20:01 2013 Received: (at 14116) by debbugs.gnu.org; 8 Apr 2013 14:20:01 +0000 Received: from localhost ([127.0.0.1]:40122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPCvR-00006j-2q for submit@debbugs.gnu.org; Mon, 08 Apr 2013 10:20:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4689) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UPCvO-00006b-SS for 14116@debbugs.gnu.org; Mon, 08 Apr 2013 10:20:00 -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.14.4/8.14.4) with ESMTP id r38EGPPq001314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 10:16:25 -0400 Received: from [10.3.113.112] (ovpn-113-112.phx2.redhat.com [10.3.113.112]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r38EGOgu029895; Mon, 8 Apr 2013 10:16:25 -0400 Message-ID: <5162D138.4070309@redhat.com> Date: Mon, 08 Apr 2013 08:16:24 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Linda Walsh Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink References: <5159C799.1060903@draigBrady.com> <51611E53.2030401@tlinx.org> In-Reply-To: <51611E53.2030401@tlinx.org> X-Enigmail-Version: 1.5.1 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2GFEAPUVARVVQWVHSLGHN" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Spam-Score: -9.3 (---------) X-Debbugs-Envelope-To: 14116 Cc: =?UTF-8?B?UsOpbXkgTGVmZXZyZQ==?= , 14116@debbugs.gnu.org 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: -9.3 (---------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GFEAPUVARVVQWVHSLGHN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/07/2013 01:20 AM, Linda Walsh wrote: >=20 >=20 > R=C3=A9my Lefevre wrote: > [>> P=C3=A1draig Brady wrote: >>> Doing that though breaks `ln -sr target1 target2 dir` where dir is a = symlink. > ] >> But could you provide me an example where the final component of the l= ink >> should be resolved ? > --- > What happens if 'dir' is a symlink, "-n" is used, and > '/' (or '/.') is appended to "dir" in the above example? According to POSIX, appending a trailing '/' requires that a name be resolved as a directory (either an actual directory, or a symlink to a directory). >=20 > Would that force 'dir' to be resolved, on the basis that > '/' would be the final component. '/' is never a final component (except for the root directory '/' where it is the only component). In POSIX parlance, a final component is determined by stripping trailing slashes (except for the special case of the root directory), then using the non-slash portion after the last remaining slash. However, the mere presence of a trailing slash does affect resolution rules, in that the component being resolved has to be a directory or a symlink to a directory. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2GFEAPUVARVVQWVHSLGHN 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.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRYtE4AAoJEKeha0olJ0NqFdsH/RCcKmsx9hdQOOOFazbMaX1w J0Eil3xidyBRN7Br+B3SKXGRfFLCnX+KiW9PhA34Igd+FOR8HJE+iT63EA+vdghe 8Sik8p13Wra23qCO+ZpehXYfwCfAlYHZQ7qkgt0Wx8QXePWNidhHIxgzJdXHnSpG NOxPCTR+ys+ZX9DHfv4d1DBkI7HM7GaE9z2xNmMDpEYW+B+12S/l9KUkC4tC1t8g TxIi+cQbkCy7GRvNmuAhMtWWjoph82Nch2bMQxEN2hP8f5MhF/7ROXPBIUXI/teW WbN3qWoos9VJjWM1YqzA6qfQ9Xg8B6lAJCDpkXor939MmrYOQzHfm7lziaphjMU= =xiPf -----END PGP SIGNATURE----- ------enig2GFEAPUVARVVQWVHSLGHN-- From unknown Mon Jun 23 13:12:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 07 May 2013 11:24:02 +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 Thu Mar 27 20:18:19 2014 Received: (at control) by debbugs.gnu.org; 28 Mar 2014 00:18:19 +0000 Received: from localhost ([127.0.0.1]:53369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WTKV0-0004Nu-HQ for submit@debbugs.gnu.org; Thu, 27 Mar 2014 20:18:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14739) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WTKUx-0004Nd-Th; Thu, 27 Mar 2014 20:18:16 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2S0IEeE001887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 20:18:14 -0400 Received: from [10.36.116.45] (ovpn-116-45.ams2.redhat.com [10.36.116.45]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2S0IB14030833 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Mar 2014 20:18:13 -0400 Message-ID: <5334BFC3.7060005@draigBrady.com> Date: Fri, 28 Mar 2014 00:18:11 +0000 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Er-Min Wang Subject: Re: bug#17126: error of relative symbolic link with directory References: <201403272349.s2RNnJpe012098@freefriends.org> In-Reply-To: <201403272349.s2RNnJpe012098@freefriends.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control Cc: 17126@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) unarchive 14116 forcemerge 14116 17126 stop On 03/27/2014 11:49 PM, Er-Min Wang wrote: > $ ln --version > ln (GNU coreutils) 8.20 > > $ mkdir -p aaa/aaa1 bbb > $ tree . > . > |-- aaa > | `-- aaa1 > `-- bbb > > $ cd aaa > $ ln -fnrsv aaa1 ../bbb/ > ‘../bbb/aaa1’ -> ‘../aaa/aaa1’ > $ ln -fnrsv aaa1 ../bbb/ > ‘../bbb/aaa1’ -> ‘aaa1’ Already fixed in the last 8.22 release: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=e52293aa You might want to log a bug with your distro to backport the fix? thanks, Pádraig. From unknown Mon Jun 23 13:12:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 25 Apr 2014 11:24:04 +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 Tue May 17 12:10:40 2016 Received: (at control) by debbugs.gnu.org; 17 May 2016 16:10:40 +0000 Received: from localhost ([127.0.0.1]:56161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2hZv-0008OQ-Ql for submit@debbugs.gnu.org; Tue, 17 May 2016 12:10:40 -0400 Received: from mail.magicbluesmoke.com ([82.195.144.49]:55784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2hZt-0008OB-57; Tue, 17 May 2016 12:10:38 -0400 Received: from [192.168.1.80] (unknown [109.76.84.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.magicbluesmoke.com (Postfix) with ESMTPSA id 7CDB24A9D; Tue, 17 May 2016 17:10:35 +0100 (IST) Subject: Re: bug#23564: Unexpected results from `ln --symbolic --interactive --relative` To: Florian Schweiger , 23564@debbugs.gnu.org References: <573AEAB6.7090608@bbc.co.uk> From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: <573B427A.9000702@draigBrady.com> Date: Tue, 17 May 2016 17:10:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <573AEAB6.7090608@bbc.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) unarchive 14116 forcemerge 14116 17126 23564 close 23564 stop On 17/05/16 10:56, Florian Schweiger wrote: > Hi, > > I've noticed the following unexpected behaviour in `ln` which appears to > be a bug. I'm referring to the attached MWE Bash script > test_ln-symbolic-interactive-relative.sh. > > When run, it creates a directory "test_dir" and a file "test_file" in > the current working directory. Then it tries to create a relative, > symbolic link to the file in said directory. When the "--interactive" > option is present, this operation fails every other time in that it > overwrites the existing link with an unreachable target. > > DETAILED DESCRIPTION: > > * First invocation > $ ./test_ln-symbolic-interactive-relative.sh > ln -sirv test_file test_dir/test_link > ‘test_dir/test_link’ -> ‘../test_file’ > * Second invocation: > $ ./test_ln-symbolic-interactive-relative.sh > ln -sirv test_file test_dir/test_link > ln: replace ‘test_dir/test_link’? y > ‘test_dir/test_link’ -> ‘test_file’ > * Third invocation: > $ ./test_ln-symbolic-interactive-relative.sh > ln -sirv test_file test_dir/test_link > ln: replace ‘test_dir/test_link’? y > ‘test_dir/test_link’ -> ‘../test_file’ > > > AFFECTED SYSTEM: > * ln (GNU coreutils) 8.21 > * GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) > * Ubuntu 14.04.4 LTS This was fixed in V8.22 with: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.21-27-ge52293a thanks, Pádraig From unknown Mon Jun 23 13:12:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 15 Jun 2016 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