From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#64401: 28.1; Desktop restoration Date: Mon, 03 Jul 2023 19:47:06 +0200 Message-ID: <87ttukopk5.fsf@gmx.de> References: <83lefzpj56.fsf@gnu.org> <83ilb3pimj.fsf@gnu.org> <87pm5au366.fsf@gmx.de> <83sfa6ogig.fsf@gnu.org> <87fs66u0ox.fsf@gmx.de> <83pm5aoclr.fsf@gnu.org> <87h6qm38i3.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22994"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: tom@tomhunt.email, 64401@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 03 19:48:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qGNeu-0005r2-Hw for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Jul 2023 19:48:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGNee-0007Ps-Bs; Mon, 03 Jul 2023 13:48:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGNed-0007Pi-1q for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 13:48:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qGNec-0007nR-OS for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 13:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qGNec-00005z-7X for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 13:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Jul 2023 17:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64401 X-GNU-PR-Package: emacs Original-Received: via spool by 64401-submit@debbugs.gnu.org id=B64401.168840643932637 (code B ref 64401); Mon, 03 Jul 2023 17:48:02 +0000 Original-Received: (at 64401) by debbugs.gnu.org; 3 Jul 2023 17:47:19 +0000 Original-Received: from localhost ([127.0.0.1]:34430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGNdv-0008UK-Ci for submit@debbugs.gnu.org; Mon, 03 Jul 2023 13:47:19 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:53957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGNdq-0008U0-W3 for 64401@debbugs.gnu.org; Mon, 03 Jul 2023 13:47:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1688406428; x=1689011228; i=michael.albinus@gmx.de; bh=x0MG4WXEC7ViCHnuzPrjcS7ab+wCGoQ9FWGxBybL0TY=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=gppMlWq1HFCQgg0jaDoNWK5sez5/LkrZKEG3Sezrog+b4+XUs1tOs0bor0VnIy0m5HeBGUU TqzR5ysiWeMlMgChFYyv+OwnIXCQgIiHgNK5/1X5v5ttPSHctb564cG2hvUJLcOm8tmM/EFNq T4huJWzjSmD+lelZ1N4wic0ehznpw3QaqCq/FF7YYebPR3wELZEb0qWXD0rJEIWoxfDQoPWMz Nz57dwsIYHYKTlhJPXkV0uFPVLuSP8jCC71IiKiHrl/+EqbL4adbuqkSy3p/fxnFTFAe+NY3k 4orE0X0l6rMRATFUFmDCVH63V00JlOcjwJCdLZoU7K/wSY/f/Gjg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.39.13]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MUowV-1qP0VW3TfN-00QjhV; Mon, 03 Jul 2023 19:47:07 +0200 In-Reply-To: <87h6qm38i3.fsf@gmx.de> (Michael Albinus's message of "Sun, 02 Jul 2023 12:36:36 +0200") X-Provags-ID: V03:K1:wNpQYCQtku9SDjUOiUSE+5rztBZXyq8G1OFIoEKYNiEvgtCWCxV o7Ssr8M3yKxYTvwZbb8WTvomQDqk60ZjsV5rD6kqhv/qtgKjgn9YgqsvhE3X+LDuyANjeDJ Ah2nvFOybjHUGLhnlO+/q1oQcuTg8zhXDnag9+i2unMr9GveHy6p0DpMcAR4QyRJ22/2PXD IBx0zaiTJ1GpylhcuAiOg== UI-OutboundReport: notjunk:1;M01:P0:CAg6Fb8OFSc=;BAsGNRifqa4FDFmUN23sGMzs//c Pl1Atu3Et/T5XQFbYH2bUNeeYECxV2bpUxF6tS+XG9GJ399zTs6lELqzspLSf11ryoS3Wh2np NtzNyhxtC3iXjUpodc3tbao+JOeiM02/RoBS1dc5HdamROOJP01eEbQIb0PcHJZOh8YHa8UhC 5XpJfdfWwAjPORMHIM82xiXq06B95Qtgv+qvE+0Oobg+x5j97J//LMUjouERv/hmUHBWkZ+6L HtymaupYxWR6yhWKOsBaYpIwQmwJeSW5XfoHdndF2ttmqA89+dzxmqB5IfW9FzMHt7QMnkp2/ WZIPTkMy1nnTO3bhi+CaGxzhK+Di+ZYleZSAiKyamGNlf7hgMB48XMOJyuvdwmGYGVdw/KY/g 111jZrENvBK1IjCVplyH6ECfYIeJerwBuYnrQNUEvqFd8WJIlNCKTEokyn+YxOVH82ew9mAqs 4HcB51Pu9zIUCqPjfzCbI8/Gs9z+2BWuTQ6s2rFaGyn0/n219xYTmI6NR6j1cUzhDKkM1UdbZ VnQWxaS47T2SyVSbZ/oJmrHCVOq2hOG/VN8/juzSJvJCRaKAeM5KJyqG4w7FHuOyxIZfPPyna CakcuRkjImpw0xX8JfWDgwaFCr2xQlDZZfBuGXeNUB9uqwt3gXTs3dogeiGiAOjDO6lPBirXF wpgcFfRgd9Bxxg5Qe0oDnSVmyvKDB56/j7jkqjzDWXvVRKtu03BZw3kNIEHcfCAYJhiYzEFQ7 y3suMNL1+F/AC/nShecqYWyBbmcDXBwdeEc3uZcPokcbcfCEdczSeV7FdpSU4/wzB/FZebZc X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264541 Archived-At: Michael Albinus writes: Hi Eli, >> Also, the implementation should probably "remember" the result and >> apply it to all the other files on the same volume? > > Hmm, this will be harder. `access-file' could fail for different > reasons. And Tramp does not know whether two remote files belong to the > same volume. Well, there is `file-attribute-device-number', but this is > not trustworthy for all different kind of remote file systems. > > I'll see whether I can implement a cache for different volumes on remote > hosts where it makes sense. Going through the Tramp implementation, there's no need for such a cache. The usual Tramp cache does it already sufficiently. Either a file has already cached information, then that's fine. Or it has no cache information, then we would need to call file-attributes first in order to get the device number, and then it is in the cache. Finally, I've pushed a fix to master along the idea sketched in this thread. I've decided to set the default of remote-file-name-access-timeout to nil (which preserves the existing behavior). There are so many different possibilities I couldn't decide for a sensitive value. The Tramp manual explains now --8<---------------cut here---------------start------------->8--- Some packages, like =E2=80=98desktop.el=E2=80=99 or =E2=80=98recentf.e= l=E2=80=99, access remote files when loaded. If the respective file is not accessible, TRAMP could block. In order to check whether this could happen, add a test via =E2=80=98access-file=E2=80=99 with a proper timeout prior loa= ding these packages: (let ((remote-file-name-access-timeout 10)) (access-file "/method:user@host:/path/to/file" "error")) =E2=87=92 nil The result =E2=80=98nil=E2=80=99 means success. If the file is not ac= cessible, or if the underlying operations last too long, =E2=80=98access-file=E2=80= =99 returns with an error. The value of the timeout (10 seconds in the example) depends on your preference and on the quality of the connection to the remote host. If the connection to the remote host isn=E2=80=99t established = yet, and if this requires an interactive password, the timeout check doesn=E2=80=99t work properly. --8<---------------cut here---------------end--------------->8--- Better would be, if desktop.el and recentf.el do this check on their own. recentf.el uses file-readable-p (in recentf-keep-default-predicate). desktop.el usually skips Tramp files (in desktop-files-not-to-save), but this could be changed. In general it uses file-exists-p (in desktop-restore-file-buffer) for a check before restoring. Both implementations should be changed to use access-file instead. Will try it next days. Do you know other packages in vanilla Emacs which could profit from this mechanism? And then we would need a good place to train users of desktop.el and recentf.el to adapt remote-file-name-access-timeout - I have no idea where. >> Thanks. Best regards, Michael.