GNU bug report logs -
#64102
28.2; fails to find pathname with a sub dir as symlink and with parent dir ('..')
Previous Next
Full log
Message #11 received at 64102 <at> debbugs.gnu.org (full text, mbox):
> Cc: 64102 <at> debbugs.gnu.org
> Date: Fri, 16 Jun 2023 10:11:49 +0300
> From: Eli Zaretskii <eliz <at> 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 <at> 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?
This bug report was last modified 2 years and 60 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.