bug#64102: 28.2; fails to find pathname with a sub dir as symlink and with parent dir ('..')

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 15 Jun 2023 22:25:56 +0000
> msip_labels: 
> From:  Jacob Burckhardt via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Reproduce the bug by running this:
> 
> mkdir -p /tmp/usr2/lib/gcc/x86_64-linux-gnu/12
> mkdir /tmp/usr2/include
> echo symbolic link test > /tmp/usr2/include/test.h
> \ln -s usr2/lib /tmp/lib2
> cat /tmp/lib2/gcc/x86_64-linux-gnu/12/../../../../include/test.h
> emacs -q /tmp/lib2/gcc/x86_64-linux-gnu/12/../../../../include/test.h
> 
> Emacs failed to display the content of that file in a buffer.  Since the above cat command shows the contents, Emacs should be able to show it as well.  The following bug is similar and includes some explanations that also apply to my bug.
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8035
> 
> Note that the following code succeeds.  You might consider using code like this to fix the bug:
> 
> (find-file (file-truename "/tmp/lib2/gcc/x86_64-linux-gnu/12/../../../../include/test.h"))

This would mean expand-file-name would need to call file-truename to
resolve such tricky symlinks, which I think is not reasonable.  We
never did that, AFAICT, and the code in find-file-noselect that begins
with expand-file-name on the argument FILENAME has been there since
1992.