Date: Mon, 22 Mar 2021 23:34:57 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 254489] ln(1) should apply -F to the file being created, not target_file (was command 'ln -sfF' behaves unreasonably: it deletes the target directory and then fails) Message-ID: <bug-254489-227-gY6XXoir9p@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-254489-227@https.bugs.freebsd.org/bugzilla/> References: <bug-254489-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254489 --- Comment #4 from Christos Margiolis <christos@christosmarg.xyz> --- > The target of the link in this case is a file .x/ls and it doesn't exist. It seems that the -F option interprets `.x/` literally, so it tries to crea= te a file named `.x/` which obviously doesn't work. You'd have to write the comm= and as `ln -sfF /bin/ls .x/ls` in order for it work the way you want it to. > When the user specifies "-F" he means "target of the link" (the object > being created). IMO a correct fix here is to fix ln(1) to apply "-F" to > the "target of the link", and to correct the manpage accordingly. I think the reason behind the fact that -F doesn't "fill in" the target's n= ame=20 (i.e `.x/` to `.x/ls`) is to prevent commands such as `ln -sfF foo .` which would mean that the current working directory has to be deleted if it's emp= ty. It makes sense that -F doesn't have the same behavior as the other options since it involves deleting stuff and the command I mentioned above is a com= mon command and very easy way to mess things up, especially if -F is used insid= e a script. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254489-227-gY6XXoir9p>