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

[Eli Zaretskii]

> Cc: 64102@debbugs.gnu.org
> Date: Fri, 16 Jun 2023 10:11:49 +0300
> From: 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.

Paul, any comments or ideas?