bug#27108: 26.0.50; tramp and recentf again

[Michael Albinus <michael.albinus@gmx.de>]

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

Stephen Berman <stephen.berman@gmx.net> writes:

Hi Stephen,

> Starting with this change:
>
>    commit dca22e86e02d16a31128c163925b13404f777c0f
>    Author: Michael Albinus <michael.albinus@gmx.de>
>    Date:   Wed May 24 16:16:53 2017 +0200
>
>      Introduce a defstruct `tramp-file-name' as central data structure.
>
> The problem also happens when I have the above recentf file and start
> emacs like this:
>
> emacs -Q --eval "(custom-set-variables '(recentf-mode t))"
>
> This recalls bug#26258 but now there is no error, just the login prompt.

Thanks for the report. I could reproduce it locally. However, I don't
know whether this counts as a bug.

The password request comes from the function
`file-name-case-insensitive-p', called when recentf scans the saved file
name list. Tramp has different approaches to implement this function;
for the sudo method (as in your case) it performs some tests on the
remote account. Usually, you don't see this, because Tramp keeps the
result of this function in its own persistency file "~/.emacs.d/tramp".

As you have observed, it didn't work this way after the switch to use
defstruct's in Tramp. Due to this change, the data in Tramp's
persistency file were invalid, and they were ignored at startup. Tramp's
`file-name-case-insensitive-p' implementation couldn't use the cached
value, and so it tried to recompute it, accessing the sudo account,
asking for the password.

As a skilled bug hunter, you have tried to find the problem by starting
further Emacs instances with "emacs -Q". But when Emacs is started with
the "-Q" argument, Tramp doesn't read its persistency file, it doesn't
know the cached value, and you have the same problem. So it looks like a
bug.

I'm pretty sure, if you continue to work the usual way, calling Emacs
w/o "-Q", the problem disappears latest after the second Emacs startup,
because the cached value is available then from the persistency
file. That's why I believe it isn't a bug.

OTOH, I understand that the problem is annoying when it appears, and
when it isn't obvious why this happens. The appended small patch in
`recentf-load-list' would avoid this, instructing Tramp not to open a
new connection while reading the previously saved recent list. Would it
be OK to apply this patch?

Best regards, Michael.


[-- Attachment #2: Type: text/plain, Size: 602 bytes --]

diff --git a/lisp/recentf.el b/lisp/recentf.el
index 4f0573911b..462ccb6db5 100644
--- a/lisp/recentf.el
+++ b/lisp/recentf.el
@@ -1304,7 +1304,9 @@ recentf-load-list
 When `recentf-initialize-file-name-history' is non-nil, initialize an
 empty `file-name-history' with the recent list."
   (interactive)
-  (let ((file (expand-file-name recentf-save-file)))
+  (let ((file (expand-file-name recentf-save-file))
+        ;; We do not want Tramp asking for passwords.
+        (non-essential t))
     (when (file-readable-p file)
       (load-file file)
       (and recentf-initialize-file-name-history