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

[Al Petrofsky <al@petrofsky.org>]

[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]

Jacob:
> 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.

Paul:
> Emacs's behavior is well-documented and longstanding. It's also wrong,
> in that it disagrees with almost every other program and it therefore
> confuses users, particularly non-experts.
>
> One possible way out would be to add a user-settable flag to select the
> longstanding Emacs behavior, or the behavior of most other programs. We
> could document that the default might change in the future. Of course
> this approach would have its own problems.

Eli:
> My take from the description of the issue is that we'd need to change
> expand-file-name to follow symlinks, i.e. hit the disk, something that
> it never did, at least not on Posix platforms.  If this is what is
> needed, it would have serious implications, at least performance-wise,
> because expand-file-name is called everywhere in Emacs where we deal
> with file names.

Perhaps another approach would be that Emacs continues to have its own
idiosyncratic understanding of pathnames internally, but pathnames
that come in from external sources are interpreted correctly according
to the rules of the external environment.

That seems to be the approach that was taken by Lars in 2021 to fix
bug 8035 (referenced by Jacob in the first message of the current
bug).  See the patch that added file-truename calls to compile.el:


http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/progmodes/compile.el?id=ee2ffd9c9eb33a17307f36ff58caec1ba79878d2

As far as I can tell, that change was made without adding a
user-settable flag to select the old behavior, nor with any
announcement in NEWS or in the manual.  Are any problems known to have
arisen yet?

The current bug could similarly be fixed by making any filename that
is obtained from the argv of emacs or emacsclient be passed through
file-truename.  I don't know how much work that would be to implement,
or how many user-confusing situations would remain and/or be created,
but at least I don't see it being a performance problem, as the cost
of an exec of emacs or emacsclient would likely dwarf the cost of the
truename calls.

[-- Attachment #2: Type: text/html, Size: 2801 bytes --]