bug#14116: [PATCH] ln: allow to overwrite relative symlink

[Rémy Lefevre]

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 <address@hidden>

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