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#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t Date: Mon, 03 Apr 2023 18:32:25 +0200 Message-ID: <878rf90vvq.fsf@gmx.de> References: <87pm8mv2ex.fsf@wavexx.thregr.org> <87pm8lqs69.fsf@gmx.de> <874jpx1fn4.fsf@wavexx.thregr.org> <87mt3pcmv3.fsf@gmx.de> <87zg7pz2yx.fsf@wavexx.thregr.org> <87v8idz2qc.fsf@wavexx.thregr.org> <87jzytqmva.fsf@gmx.de> <87iledypuz.fsf@wavexx.thregr.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21661"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 62614@debbugs.gnu.org To: Yuri D'Elia Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 03 18:33:32 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 1pjN7c-0005Mp-H1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Apr 2023 18:33:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjN7I-0002Eo-19; Mon, 03 Apr 2023 12:33:12 -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 1pjN78-0001g9-DZ for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 12:33:02 -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 1pjN78-0000QJ-3S for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 12:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pjN77-0000I3-Nu for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 12:33:01 -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 Apr 2023 16:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62614 X-GNU-PR-Package: emacs Original-Received: via spool by 62614-submit@debbugs.gnu.org id=B62614.16805395551082 (code B ref 62614); Mon, 03 Apr 2023 16:33:01 +0000 Original-Received: (at 62614) by debbugs.gnu.org; 3 Apr 2023 16:32:35 +0000 Original-Received: from localhost ([127.0.0.1]:45087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjN6h-0000HO-16 for submit@debbugs.gnu.org; Mon, 03 Apr 2023 12:32:35 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:57419) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjN6e-0000HA-Cn for 62614@debbugs.gnu.org; Mon, 03 Apr 2023 12:32:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1680539546; i=michael.albinus@gmx.de; bh=VAj7EWfCaPbN3UdbH0/GfOusUT+PbQPxGOeMQsYo8hU=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=XH5rNSrKtwG9BNmfiykZCkTXjKMwpCKTE+jlYHfjCwJLiDxfUHv9LG3+1nZmOjIwB MtNQuWPF6u9mxgFZtlAJeNFc7xHp/hbtk5il4sZcYLj3McUlAF0/WkG0j32Wy9xCfz mWGAihTWfKZsLRvdBEKHlq6M8PqhajSzcOkxAku6laoGFeJv5GT8TDh7Ei8qBZFykJ ecTUl4e3RYz84zBLkP+GCw+nMo71wiJZr4Tvjsn9gL/5NbLOJUNWMgM79WiCSWIex9 5mfGQNm2Olk7lRBtYB8WMT/JHzZSmiLY3KKY5XWA3Jt0ZzJVFoTq//w1IWwNiFl3lQ Jq9gIVsK4BKSw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.39.0]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MGz1f-1pedsf178l-00E3Gn; Mon, 03 Apr 2023 18:32:26 +0200 In-Reply-To: <87iledypuz.fsf@wavexx.thregr.org> (Yuri D'Elia's message of "Mon, 03 Apr 2023 16:54:12 +0200") X-Provags-ID: V03:K1:1V8d64v80xsJQcP6TbZYUIwaLQ4z9C4IaCEjhNH4aYXkMQgmKWl CAJZ32miM0GfCCvbKF9larzCcPb259pONzzC4/Q/xFnwIbO84gBFliiTudfEqXBC/qAyZD4 kub73avuwNcNlwEcJzlNQJeMjsT2hk+5nqjZIxCqyisXQ2KZBBUvUteKFQKFSodm5K3G9K+ vWkR4Ox6r/REJzpH6090A== UI-OutboundReport: notjunk:1;M01:P0:/xLlc9I7rWU=;Rv2h3+I+toxqwuJEKLNoqERs9Qo IGcleLl3SBn80VnQAlYyyM2F4r/6TLp7XTjHs6WWaU3A36qHCIxijV95MzCOpXGLjEYH9Ql57 pg6Dtc8nNMiROSpbtm094blGl4+gSXV93n2S4MQN2hkWKCDeayKuGv6BwS+DEWrrf0RZQrf61 uMfjGQt8SOtLXxF7cw/HmCbd4n3DdD55QwaR13bNEylXDR8r6fSWUWsPEbuQ2kyZnuhZVBzfG ctf8H0YXeGQQsa+6y3PaD/JZ4GeFJQJN57wcL+mln1GK3A04xherCNYOsSjbkgkSba8KwbMzA v2Vcu17bjWzP7nQddMxvPL+Auih7BEHwB2kifCrvbDxmQsTOUPIdNKRiO7xKjWNrsK+ave1UO 4Gaep6j0epCUR4n9lmywxFDZRUZ09a/3ulZXOW1qS1NIC1XcXE5rFv4FnxlnUL9+PoMfp2yb7 doIO52z9LWHqit//uBWCWzt4xOKsBbR9UYhNfAJx/PM3uw9gMsuUy8tmnqIG5WfYp7JpQ2buQ x8q97AgxgjykFRowzohrjlf/BtsGMZ20iuLG0G7wY9OCM2xzBTjQ2ohIlGW8MBdhlSEWXRxPi wbYSBat87twWWKKrtPNpQUW8PU8KFj0vdDXZTSyg8OVIHiorZmvRqIZJKLA4FPv024Dznq1Az d6GvJVbc2hBOx7u/bz4E1wOHJaBtTSh7Gs4jetd68dkz+Hct/ODfcIn2mD4tfeQt0Kok8zivj oHYNmlMe5ZKSafOvQK2L5ghegALbzSuOd2M1gH9zC90q027igdtNTlDHE0TF9zCQVgwedT2s 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:259195 Archived-At: --=-=-= Content-Type: text/plain Yuri D'Elia writes: Hi Yuri & Eli, > On Mon, Apr 03 2023, Michael Albinus wrote: >>> IMHO if lock creation is inhibited, we could still attempt to remove the >>> lock to keep the old behavior, but then the warning shouldn't be >>> generated as you don't expect the lock to exist in the normal case. >> >> That might be an option. But it wouldn't fix your use case, where you >> try to avoid the file locking machinery for remote files at all. > > No, but it would fix an unexpected warning for both tramp and local > files, which I think is beneficial. > > On Mon, Apr 03 2023, Eli Zaretskii wrote: >> How about trying to remove the lock file, but if creation of lock >> files is disabled, suppressing the warning? > > As above. See appended patch. Shall it go to the emacs-29 or master branch? Best regards, Michael. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable diff --git a/lisp/files.el b/lisp/files.el index d325729bf4d..216d31c737b 100644 =2D-- a/lisp/files.el +++ b/lisp/files.el @@ -555,7 +555,7 @@ lock-file-name-transforms :version "28.1") (defcustom remote-file-name-inhibit-locks nil - "Whether to use file locks for remote files." + "Whether to create file locks for remote files." :group 'files :version "28.1" :type 'boolean) diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el index df2f0850b83..4180a32b6d9 100644 =2D-- a/lisp/net/tramp.el +++ b/lisp/net/tramp.el @@ -4585,7 +4585,8 @@ tramp-handle-unlock-file (condition-case err (delete-file lockname) ;; `userlock--handle-unlock-error' exists since Emacs 28.1. - (error (tramp-compat-funcall 'userlock--handle-unlock-error err))))= ) + (error (and (not (bound-and-true-p remote-file-name-inhibit-locks)) + (tramp-compat-funcall 'userlock--handle-unlock-error er= r)))))) (defun tramp-handle-load (file &optional noerror nomessage nosuffix must-= suffix) "Like `load' for Tramp files." diff --git a/lisp/userlock.el b/lisp/userlock.el index 61f061d3e54..562bc0a0a9f 100644 =2D-- a/lisp/userlock.el +++ b/lisp/userlock.el @@ -206,11 +206,12 @@ ask-user-about-supersession-help ;;;###autoload (defun userlock--handle-unlock-error (error) "Report an ERROR that occurred while unlocking a file." - (display-warning - '(unlock-file) - ;; There is no need to explain that this is an unlock error because - ;; ERROR is a `file-error' condition, which explains this. - (message "%s, ignored" (error-message-string error)) - :warning)) + (when create-lockfiles + (display-warning + '(unlock-file) + ;; There is no need to explain that this is an unlock error because + ;; ERROR is a `file-error' condition, which explains this. + (message "%s, ignored" (error-message-string error)) + :warning))) ;;; userlock.el ends here --=-=-=--