bug#53223: 27.2; multi-hop TRAMP with find-file-visit-truename t

[Aleksei Fedotov]

>> I've spotted a problem with TRAMP when using multi-hop ssh with
>> find-file-visit-truename set to t.
>>
>> Assuming that there is a remote machine XXX.YYY.com with SSH server. On local
>> machine I run emacs like that:
>>
>>> emacs -Q --eval '(progn \
>>>       (require (quote tramp)) \
>>>       (setq find-file-visit-truename t) \
>>>       (with-current-buffer (find-file 
>>> "/ssh:root@XXX.YYYY.com|ssh:localhost:") \
>>>       (tramp-cleanup-all-connections) \
>>>       (revert-buffer)))'
>>
>> It successfully connects to the remote machine and opens dired buffer with 
>> the
>> correct content, but the filename name in the dired header is not
>> '/ssh:XXX.YYYY.com|ssh:localhost:' as I might expect, but
>> '/ssh:localhost:/root:'. After (revert-buffer) I get an error in *Messages*:
>>
>>> tramp-handle-access-file: Reading directory: No such file or directory 
>>> /ssh:localhost:/root/
>>
>> The issue does not reproduce if find-file-visit-truename set to nil. It 
>> looks like 'file-truename' doesn't work correctly with multi-hop tramp file 
>> names.
>
> Tramp behaves as expected. You use an ad-hoc multi-hop remote file
> name. Such ad-hoc definitions are removed when you call
> `tramp-cleanup-all-connections'. This is described in the Tramp manual
> (info "(tramp) Ad-hoc multi-hops")
> (info "(tramp) Cleanup remote connections")
>
> If you want to keep multi-hop definitions permanently, configure
> `tramp-default-proxies-alist' as described in the Tramp manual, or set
> `tramp-save-ad-hoc-proxies' to t. See (info "(tramp) Multi-hops")

It works exactly as described in the documentaion, but what is bothering me is
the difference in behaviour depending on the state of
`find-file-visit-truename'. It should only affect symlink resolution, but it
also changes Tramp behaviour.

If `find-file-visit-truename' is set to nil, then Tramp is able to revert the
buffer and add a multi-hop definition back to `tramp-default-proxies-alist'.
If `find-file-visit-truename' is set to t, then it doesn't work. Shouldn't the
buffer somehow preserve the full path?

-- 
Aleksei