GNU bug report logs - #6052
Is this "ln" bug?

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: "Hoisko, Sakari (EXT-TietoEnator - FI/Tampere)" <sakari.hoisko.ext <at> nsn.com>
Subject: bug#6052: closed (Re: bug#6052: Is this "ln" bug?)
Date: Tue, 27 Apr 2010 15:21:02 +0000

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

Your bug report

#6052: Is this "ln" bug?

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 6052 <at> debbugs.gnu.org.

-- 
6052: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6052
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: "Hoisko, Sakari (EXT-TietoEnator - FI/Tampere)" <sakari.hoisko.ext <at> nsn.com>
Cc: 6052-close <at> debbugs.gnu.org
Subject: Re: bug#6052: Is this "ln" bug?
Date: Tue, 27 Apr 2010 16:20:07 +0100

On 27/04/10 14:16, Hoisko, Sakari (EXT-TietoEnator - FI/Tampere) wrote:
> Hi,
> 
> Do you have some reason why -f (forced) parameter works ok if
> destionation where link point is a file, then it could update link by
> using forced mode.
> If destionation where link point is folder then -f parameter not update
> link in this situation.

That's because it's first dereferencing the passed symlink.
When updating links I use -n like:

ln -nsf $new_target link_name

cheers,
Pádraig.

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

From: "Hoisko,
	Sakari (EXT-TietoEnator - FI/Tampere)" <sakari.hoisko.ext <at> nsn.com>
To: <bug-coreutils <at> gnu.org>
Subject: Is this "ln" bug?
Date: Tue, 27 Apr 2010 16:16:41 +0300

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

Hi,

Do you have some reason why -f (forced) parameter works ok if
destionation where link point is a file, then it could update link by
using forced mode.
If destionation where link point is folder then -f parameter not update
link in this situation.

	[user <at> server linkki_testi]$ ll
	total 16
	drwxrwxr-x  4 user xxx 4096 Apr 27 14:21 .
	drwxrwxr-x  9 user xxx 4096 Apr 27 14:20 ..
	drwxrwxr-x  2 user xxx 4096 Apr 27 14:21 EKA_DIR
	drwxrwxr-x  2 user xxx 4096 Apr 27 14:21 TOKA_DIR
	[user <at> server linkki_testi]$ ln -sf
/home/user/tmp/linkki_testi/EKA_DIR
/home/user/tmp/linkki_testi/linkki_DIR
	[user <at> server linkki_testi]$ ll
	total 16
	drwxrwxr-x  4 user xxx 4096 Apr 27 14:21 .
	drwxrwxr-x  9 user xxx 4096 Apr 27 14:20 ..
	drwxrwxr-x  2 user xxx 4096 Apr 27 14:21 EKA_DIR
	lrwxrwxrwx  1 user xxx   39 Apr 27 14:21 linkki_DIR ->
/home/user/tmp/linkki_testi/EKA_DIR
	drwxrwxr-x  2 user xxx 4096 Apr 27 14:21 TOKA_DIR
	[user <at> server linkki_testi]$ ln -sf
/home/user/tmp/linkki_testi/TOKA_DIR
/home/user/tmp/linkki_testi/linkki_DIR
	[user <at> server linkki_testi]$ ll
	total 16
	drwxrwxr-x  4 user xxx 4096 Apr 27 14:21 .
	drwxrwxr-x  9 user xxx 4096 Apr 27 14:20 ..
	drwxrwxr-x  2 user xxx 4096 Apr 27 14:22 EKA_DIR
	lrwxrwxrwx  1 user xxx   39 Apr 27 14:21 linkki_DIR ->
/home/user/tmp/linkki_testi/EKA_DIR
	drwxrwxr-x  2 user xxx 4096 Apr 27 14:21 TOKA_DIR
	[user <at> server linkki_testi]$
	As you could see link still point to "EKA_DIR"... it should
point to "TOKA_DIR" because there was -f parameter defined in ln
command. 

BR.
-sakke

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

Previous Next

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