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

[Pádraig Brady]

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.