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 11:54:08 +0200 Message-ID: <87mt3pcmv3.fsf@gmx.de> References: <87pm8mv2ex.fsf@wavexx.thregr.org> <87pm8lqs69.fsf@gmx.de> <874jpx1fn4.fsf@wavexx.thregr.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25092"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 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 11:55:20 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 1pjGuG-0006LE-Gu for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Apr 2023 11:55:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjGu1-0002cZ-L3; Mon, 03 Apr 2023 05:55:05 -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 1pjGtz-0002cH-Ll for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 05:55: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 1pjGty-0005Cg-UW for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 05:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pjGty-0000Ah-F8 for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 05:55: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 Apr 2023 09:55:02 +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.1680515661450 (code B ref 62614); Mon, 03 Apr 2023 09:55:02 +0000 Original-Received: (at 62614) by debbugs.gnu.org; 3 Apr 2023 09:54:21 +0000 Original-Received: from localhost ([127.0.0.1]:43375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjGtJ-00007C-1d for submit@debbugs.gnu.org; Mon, 03 Apr 2023 05:54:21 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:55755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjGtD-00006q-7w for 62614@debbugs.gnu.org; Mon, 03 Apr 2023 05:54:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1680515649; i=michael.albinus@gmx.de; bh=1U0isG3NBKcZvwW7nT3IN5JPB3mmpBLYA96zlrrVup8=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=pZ69/T0N4m2ODrWxWpvsPFJ8YJ5mdi7qeqsSZC2qMY1ngvPdDZMOq39bURHngzr8O qNBPdIqC22e3WkRD8/uUMJfplBhO7kWt5SXNhi7Kpjy89rsX6GDyF9yBa9LL+3eP8G g9GqW14fyctjYr8cVJ5k+Rg2qnL/KHpQoREmPwCsaZqNUSQEPj2oOOEWiQ/fZu3+QZ +eG0Sx/2QuB/T8ue+jQ/+peY3rEBuQp/+zQWL1VP/cyFs7ro3SuZmt07UPaqtW/UFO HMzM5B1OJbMwk0/OtLoDjmxTfNgFsGNs7VgIJjRL+3NDiRmXDKytrLOjXnsCGKAnUj DQMXNd0FUFjjQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.39.0]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mk0JW-1q7J730hrc-00kORP; Mon, 03 Apr 2023 11:54:09 +0200 In-Reply-To: <874jpx1fn4.fsf@wavexx.thregr.org> (Yuri D'Elia's message of "Mon, 03 Apr 2023 11:19:19 +0200") X-Provags-ID: V03:K1:STZfm6jnRdEyHf9Zf6ltuCWGO1vtneJpRpvV2Z4yK8HsULmhgMQ GIrXiQqiTzWQAoDPt22KTlCIeIWykXOszEGkw2ImYFgTOwvCUWFaB206tvBFWO79hx9BfUL sC7eneKpZUxO2fpzIrFGBR0RaL1S4Hkxohewv3oJOSl2rJeHLznEuOToQ17jOmPXf4tM3al 93cZ2GlulBEJU0YfqJrvw== UI-OutboundReport: notjunk:1;M01:P0:UF0VWsGs5xo=;1i6Vy3euuBbdBXrt9Y9Ox4chDIZ +iY2XWPGuUZcE4SXtqMWKrxsr1Rwq2JmPAD6JzMzGNPByQpeo0AuB3WwGL0ht1oobRu8sOqHC 7FmbWcLCC7GC7sIkk0kVYqyqE65mQTj/czYdgwlIfmnObGAej58IRGQ/rF46R+5DI8xfk9P7i 0TwSLEcypiCqQXLboPd2skNEr9HYvx0xq3QSMDvVShIy3eqtHN5NjbKTCXJ/zJS8fXI4SioGl BJavFUX8XKUKPln89NDLFgXPBRdVHPpKvEYSZqc9+fWr2MYHbQKet9EmcLKmgm9lWiyOdbdNi 1CWAqF+cQaCDHBD595VlZi0kIK1VPgXdpsS7w5ivblG3M21/910+SYuDf3PxVpTN0/B6u7X8+ qypZUc1v0dUPhgB7Azqla+JAW5jgOt0jYhnyCMAE5gJM0FEzXTao+aIZbwPxsMUk/YQ+13lN/ FYSxzpj0OP3vcXvqAOMy9hOQ9XCJhBwsQztJ2N9nvYPJgAWLCKL/kn4pAAadvk2Ee68xzm+Pk H4xFn5CMsV95eU7230KNJEs3TylP9BXeAn7SY5TpTOw8lwifomPXONjs7SWfv1+qV9bruZ/pE Tk6igOnofBpk+3zlaRWNcbPjQuHlXtv2Iax0chx4Bf9Uh2P07Cj9Q1Yak6XQ08PChR50EGze6 DQKDLpc99NLO578H1bLgp25/oytfTh4hVv7cjwVCW0i6uET91Z3rgROriDdV9Q02SinJENSoA SXIjbMC0BP+Y6sNjoRjIxMbH94P9SIk1D4R7g5AX3GlMHotv2nob1IYKbLFHR2/1xmmK867s 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:259165 Archived-At: Yuri D'Elia writes: Hi Yuri, > Mmmh, maybe it should be mentioned explicitly. For me, "inhibit-locks" > meant inhibiting both creation and removal. > > But even for local files, why the unlock is done? For cleanup? Don't know, this behavior is "since ever" (I don't remember a change here). With Tramp I'm agnostic. Tramp follows the behavior of local files. It could do it differently, the local behavior could change, whatever. Opinions? >> One possible workaround for you would be to eval the following form, >> additionally to your settings: >> >> (fset #'tramp-handle-unlock-file #'ignore) > > Looking at the definition of #'tramp-handle-unlock-file, it does > actually look the most reasonable thing to do, but somehow having to > fset an internal function doesn't feel right, but I don't have a better > proposal since we don't have any setting that inhibit lock handling > completely. As said, it would be a workaround for your expectations. I won't document it as global solution. Best regards, Michael.