GNU bug report logs - #14116
[PATCH] ln: allow to overwrite relative symlink

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14116 in the body.
You can then email your comments to 14116 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rémy Lefevre <lefevreremy <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: [PATCH] ln: allow to overwrite relative symlink
Date: Mon, 1 Apr 2013 16:40:59 +0200

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

[patch.diff (application/octet-stream, attachment)]

Message #8 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Rémy Lefevre <lefevreremy <at> gmail.com>
Cc: 14116 <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Mon, 01 Apr 2013 18:44:57 +0100

On 04/01/2013 03:40 PM, Rémy 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 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ádraig.

Message #11 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Rémy Lefevre <lefevreremy <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 14116 <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Mon, 1 Apr 2013 22:10:25 +0200

[Message part 1 (text/plain, inline)]

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émy.


2013/4/1 Pádraig Brady <P <at> draigbrady.com>

> On 04/01/2013 03:40 PM, Rémy 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 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ádraig.
>

[Message part 2 (text/html, inline)]

Message #14 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Rémy Lefevre <lefevreremy <at> gmail.com>
Cc: 14116 <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Tue, 02 Apr 2013 01:16:12 +0100

On 04/01/2013 09:10 PM, Rémy Lefevre wrote:
> Rémy.
> 
> 
> 2013/4/1 Pádraig Brady <P <at> draigbrady.com <mailto:P <at> draigbrady.com>>
> 
>     On 04/01/2013 03:40 PM, Rémy 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 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.
>
> 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ádraig.

Message #17 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Rémy Lefevre <lefevreremy <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 14116 <14116 <at> debbugs.gnu.org>
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Tue, 2 Apr 2013 12:30:46 +0200

[Message part 1 (text/plain, inline)]

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émy.


2013/4/2 Pádraig Brady <P <at> draigbrady.com>

> On 04/01/2013 09:10 PM, Rémy Lefevre wrote:
> > Rémy.
> >
> >
> > 2013/4/1 Pádraig Brady <P <at> draigbrady.com <mailto:P <at> draigbrady.com>>
> >
> >     On 04/01/2013 03:40 PM, Rémy 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 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.
> >
> > 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ádraig.
>

[Message part 2 (text/html, inline)]

[patch.diff (application/octet-stream, attachment)]

Message #22 received at 14116-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Rémy Lefevre <lefevreremy <at> gmail.com>
Cc: 14116-done <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Wed, 03 Apr 2013 18:43:53 +0100

[Message part 1 (text/plain, inline)]

On 04/02/2013 11:30 AM, Rémy Lefevre wrote:
> 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.

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ádraig.

[ln--relative--symlink.patch (text/x-patch, attachment)]

Message #25 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: 14116 <at> debbugs.gnu.org, P <at> draigBrady.com, lefevreremy <at> gmail.com
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Thu, 04 Apr 2013 01:06:28 +0200

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

Message #28 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: lefevreremy <at> gmail.com, 14116 <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Thu, 04 Apr 2013 02:48:22 +0100

On 04/04/2013 12:06 AM, Bernhard Voelker wrote:
> 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.

Thanks for the review!

Pushed.

Message #31 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Rémy Lefevre <lefevreremy <at> gmail.com>
Cc: 14116 <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Sun, 07 Apr 2013 00:20:51 -0700

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.

	

Message #34 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: Rémy Lefevre <lefevreremy <at> gmail.com>,
	14116 <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Sun, 07 Apr 2013 11:36:31 +0100

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.

Message #37 received at 14116 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: Rémy Lefevre <lefevreremy <at> gmail.com>,
	14116 <at> debbugs.gnu.org
Subject: Re: bug#14116: [PATCH] ln: allow to overwrite relative symlink
Date: Mon, 08 Apr 2013 08:16:24 -0600

[Message part 1 (text/plain, inline)]

On 04/07/2013 01: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?

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).

> 
> 	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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.