[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible bug in 'ln -s target dir' check code --
From: |
Perry Hutchison |
Subject: |
Re: Possible bug in 'ln -s target dir' check code -- |
Date: |
Mon, 29 Jul 2019 00:42:35 -0700 |
User-agent: |
nail 11.25 7/29/05 |
"Townsend, Paul" <address@hidden> wrote:
> I am probably incorrectly interpreting the autoconf code that
> checks whether or not 'ln -s target dir' works. It seems the
> check code is satisfied if
>
> mkdir a
>
> touch b
>
> ln -s b a
>
> works without aborting. On Ubuntu this does create a 'b' symlink
> in 'a' but that symlink is an infinite a/b->a/b.
AFAIK this has been the normal behavior of "ln -s" for as long
as symlinks have existed. Indeed, because "ln -s" (unlike "ln"
without -s) does not stat the link target, it would still work
even if you left out the "touch b".
> In fact I think the only way to succeed is to use
>
> ln -s $PWD/b a
or, better, "ln -s ../b a"
One way to help keep such things straight is to make symlinks only
in the current directory, e.g.
( cd a && ln -s ../b . )
> i.e., the ln app should be a heck of a lot smarter.
Arguably it should have originally been designed to issue a warning
if the target does not exist or if the result will be a loop, but to
change its behavior now would break backward compatibility.