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

[Eli Zaretskii]

> From: Al Petrofsky <al@petrofsky.org>
> Date: Sun, 18 Jun 2023 16:13:16 -0400
> 
> > 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.

This bug report is against what happens when visiting files given by
their name.  Emacs visits files in umpteen different ways, and they
all need to behave consistently.  Moreover, Emacs often visits files
or inserts their contents internally, for various processing purposes,
such, for example, processing of .mailalias files, save-place files,
etc.  If some of these features resolve symlinks in all the
directories, but others don't, this will be a source of constant user
surprise and complaints.

> 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

That changed a single place where using the resolved names solved a
particular problem in some internal processing step.  What is being
discussed here is a completely different, much more general problem.

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

That's just two ways Emacs gets a file name that it is asked to visit.
It won't solve the following slight variation of the original report:

  emacs -q
  C-x C-f /tmp/lib2/gcc/x86_64-linux-gnu/12/../../../../include/test.h RET

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

The performance problem will happen if we make expand-file-name
resolve all the symlinks.  That is the solution I had in mind, and
AFAIU it is the _only_ solution that will produce consistent results.

However, maybe I'm missing some clever alternative.  Which is why I
asked Paul to describe what he had in mind.  But solving it one case
at a time is definitely not TRT.