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

Previous Next

Full log

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.

Previous Next

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