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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254489 --- 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 create a file named `.x/` which obviously doesn't work. You'd have to write the command 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 name (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 empty. 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 common command and very easy way to mess things up, especially if -F is used inside a script. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254489-227-gY6XXoir9p>