From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuri D'Elia 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 12:17:06 +0200 Message-ID: <87v8idz2qc.fsf@wavexx.thregr.org> References: <87pm8mv2ex.fsf@wavexx.thregr.org> <87pm8lqs69.fsf@gmx.de> <874jpx1fn4.fsf@wavexx.thregr.org> <87mt3pcmv3.fsf@gmx.de> <87zg7pz2yx.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="38187"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.10.0; emacs 30.0.50 To: Michael Albinus , 62614@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 03 12:21: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 1pjHJP-0009jI-KT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Apr 2023 12:21:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjHJB-0007Xa-PE; Mon, 03 Apr 2023 06:21: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 1pjHJ8-0007VZ-4p for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 06:21: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 1pjHJ7-0003Lo-Sq for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 06:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pjHJ7-0000px-OE for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 06:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuri D'Elia Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Apr 2023 10:21: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.16805172313158 (code B ref 62614); Mon, 03 Apr 2023 10:21:01 +0000 Original-Received: (at 62614) by debbugs.gnu.org; 3 Apr 2023 10:20:31 +0000 Original-Received: from localhost ([127.0.0.1]:43388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjHId-0000os-7V for submit@debbugs.gnu.org; Mon, 03 Apr 2023 06:20:31 -0400 Original-Received: from erc.thregr.org ([46.43.2.63]:60170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjHIa-0000ok-QZ for 62614@debbugs.gnu.org; Mon, 03 Apr 2023 06:20:29 -0400 Original-Received: from [37.163.233.240] (helo=localhost) by erc.thregr.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1pjHId-000qhH-2B (envelope-from ); Mon, 03 Apr 2023 12:20:31 +0200 In-reply-to: <87zg7pz2yx.fsf@wavexx.thregr.org> 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:259168 Archived-At: On Mon, Apr 03 2023, Yuri D'Elia wrote: > On Mon, Apr 03 2023, Michael Albinus wrote: >> 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? > > I fully agree with you that it should follow the behavior of local files > too, so I wouldn't change anything here _just_ for tramp. Thinking loudly, if we inhibit lock creation, what's your opinion on the unlock warning (for the generic local case)? 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.