bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

[Warren Parad]

except mv(1) and cp(1) are both "FROM" and then "TO", but ln is backwards
from thi, it is "TO" then "FROM", the least the command could do is put
these in the correct order.

>  it is a one-time effort to learn the order
Opinion, do you want proof that people can't learn this, because they
haven't.

> The synopsis is already complex and confusing enough:
Opinion, it is as complex as it allows, sounds like you are saying "LN
Sucks, we really need 4 commands which are all simpler", sure okay we can
have another command, but doing the right thing ALWAYS takes precedence
over "I have an opinion"

> what happens if another (malicious?) user B creates LINK_TARGET while
user A is typing the command?
While typing before entering? Then it doesn't matter if they are reversed
since the command would still fail because both exist, that should result
in the only real failure. I'm not suggesting removing the error in all
cases.

>   $ ln -nsvf somename othername
WTF, yeah let's tell everyone that gets this wrong to delete the file they
want to link, that's a genius idea.

On Fri, Nov 26, 2021 at 12:02 AM Bernhard Voelker <mail@bernhard-voelker.de>
wrote:

> On 11/25/21 18:53, Warren Parad wrote:
> > It is too frequent a problem to know which is the correct order of TARGET
> > and LINK_NAME.
>
> I disagree: it is a one-time effort to learn the order ... similar as
> for mv(1) and cp(1).
>
> > Since the command already believes that it can't create a link to a file
> > which already exists (and for hard links that the TARGET must also
> exist),
> > instead of complaining, the command should just switch the order of the
> > parameters.
>
> The synopsis is already complex and confusing enough:
>
>   Usage: ln [OPTION]... [-T] TARGET LINK_NAME
>     or:  ln [OPTION]... TARGET
>     or:  ln [OPTION]... TARGET... DIRECTORY
>     or:  ln [OPTION]... -t DIRECTORY TARGET...
>
> and especially surprising if LINK_NAME is a directory name which the caller
> wasn't aware of.  Letting ln(1) automagically swap the parameters if
> LINK_NAME
> exists simply adds more confusion and opens maybe a big race window:
> what happens if another (malicious?) user B creates LINK_TARGET while user
> A
> is typing the command?
>
> Personally, I recommend the following option combination which results in
> less surprises (see other cases below):
>
>   $ ln -nsvf somename othername
>
> Especially when creating symlinks, I prefer to get an error early rather
> than
> ending up with a symlink with a name or location I never would have
> expected.
>
> Have a nice day,
> Berny
>