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

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

[Aleksei Fedotov]

Hi,

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.


In GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-08-07 built on buildvm-x86-31.iad2.fedoraproject.org
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Fedora Linux 35 (Workstation Edition)

Recent messages:
Tramp: Found remote shell prompt on ‘XXX.YYY.com’
Tramp: Sending command ‘exec ssh    -e none localhost’
Tramp: Waiting for prompts from remote shell...done
Tramp: Found remote shell prompt on ‘localhost’
Tramp: Opening connection for localhost using ssh...done
Tramp: Opening connection for localhost using ssh...
Tramp: Sending command ‘exec ssh    -e none localhost’
Tramp: Waiting for prompts from remote shell...done
Tramp: Found remote shell prompt on ‘localhost’
Tramp: Opening connection for localhost using ssh...done
tramp-handle-access-file: Reading directory: No such file or directory /ssh:localhost:/root/
Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
 --with-cairo --with-json build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER GMP

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny rfc822 mml easymenu
mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils tramp-cmds dired dired-loaddefs tramp-sh
tramp-cache tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat shell pcomplete comint ansi-color ring parse-time iso8601
time-date ls-lisp format-spec auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs cl-loaddefs cl-lib password-cache json subr-x map
seq byte-opt gv bytecomp byte-compile cconv tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting xwidget-internal cairo move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 67308 9233)
 (symbols 48 8131 1)
 (strings 32 24241 1892)
 (string-bytes 1 868840)
 (vectors 16 14042)
 (vector-slots 8 184813 11864)
 (floats 8 40 21)
 (intervals 56 271 0)
 (buffers 1000 13))


-- 
Aleksei

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

[Michael Albinus]

Aleksei Fedotov <aleksei@fedotov.email> writes:

> Hi,

Hi Aleksei,

> 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")

Best regards, Michael.

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

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

[Michael Albinus]

Aleksei Fedotov <aleksei@fedotov.email> writes:

Hi Aleksei,

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

It isn't just a find-file-visit-truename problem. Tramp cleans up ad-hoc
multi-hop proxies when tramp-cleanup-all-connections is performed. This
could happen for many different Tramp file name operations, not just
file truenames. It is sheer luck for you that the example works when you
haven't set find-file-visit-truename.

If you replace tramp-cleanup-all-connections by tramp-cleanup-this-connection
in your example, it works as expected.

Best regards, Michael.

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

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Aleksei,

>> 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?
>
> It isn't just a find-file-visit-truename problem. Tramp cleans up ad-hoc
> multi-hop proxies when tramp-cleanup-all-connections is performed. This
> could happen for many different Tramp file name operations, not just
> file truenames. It is sheer luck for you that the example works when you
> haven't set find-file-visit-truename.
>
> If you replace tramp-cleanup-all-connections by tramp-cleanup-this-connection
> in your example, it works as expected.

No further comment, so I close this bug.

Best regards, Michael.