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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Rémy Lefevre <lefevreremy <at> gmail.com>
Subject: bug#14116: closed (Re: bug#14116: [PATCH] ln: allow to overwrite
 relative symlink)
Date: Wed, 03 Apr 2013 17:48:02 +0000

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

Your bug report

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

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 14116 <at> debbugs.gnu.org.

-- 
14116: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14116
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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 3 (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 part 5 (message/rfc822, inline)]

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 6 (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 7 (text/html, inline)]

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

Previous Next

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