bug#42706: 27.0.50; commands breaking on unreachable remote directory [was: Re: master 3e4d4f472d: Rework `abbreviate-file-name' in Tramp]

bug#42706: 27.0.50; commands breaking on unreachable remote directory [was: Re: master 3e4d4f472d: Rework `abbreviate-file-name' in Tramp]

[Michael Albinus]

[Changing subject and adding 42706@debbugs.gnu.org to Cc]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> On Fri, Mar 11, 2022 at 12:45 AM Michael Albinus <michael.albinus@gmx.de> wrote:
>> Btw, while you're at this: could you have a look on bug#42706? It is
>> related to abbreviate-file-name and Tramp. When it was reported,
>> abbreviate-file-name wasn't handled by Tramp, so nobody did any action
>> :-( But now we have tramp-handle-abbreviate-file-name and could do
>> something, perhaps.
>
> I tried, but wasn't able to reproduce that issue on Emacs 27.2, so
> it's hard to say if things are any better in Emacs 29. I tried by
> starting "emacs -Q", opening a file over Tramp, and then turning off
> my remote device. While I couldn't connect to the remote host anymore
> (as you'd expect), `list-buffers' seemed to work fine, and `cd' showed
> the prompt correctly. Actually trying to change the directory timed
> out, but that's normal.

Well I've tried to reproduce the scenario of the OP with Emacs 27.2,
which wasn't trivial due to missing information. However, the backtraces
show invocation of tramp-archive-file-name-handler, which gave me the
idea, that the OP has applied a remote file name archive, and from
within that the problems happened.

Remote file name archives, handled by Tramp, are possible only on a
local GNU/Linux machine. See the Tramp manual for a description.

In order to reproduce the problem, I have opened a file archive 123.tar
on a remote machine, like

emacs -Q /scp:user@host:tmp/123.tar/

The trailing slash is important. Afterwards, I have disabled the
LAN/WLAN connection of my machine. Then I have called "M-x cd" in that
buffer.

With both Emacs 27.2 and Emacs 29 (from git master) I've got the same
backtrace as reported by the OP. So I guess we have to dig somewhere
else.

> - Jim

Thanks for your investigation, and best regards, Michael.