From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Jay Berkenbilt" Newsgroups: gmane.emacs.bugs Subject: bug#53207: 28.0.91; create-lockfiles nil breaks file change detection Date: Thu, 13 Jan 2022 08:11:34 -0500 Message-ID: References: <509ddd0f-589c-45b0-9b60-5820f4c1d716@www.fastmail.com> <83sftr3nyx.fsf@gnu.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="12712"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.5.0-alpha0-4569-g891f756243-fm-20220111.001-g891f7562 Cc: 53207@debbugs.gnu.org To: "Eli Zaretskii" , "Glenn Morris" , "Michael Albinus" , "Lars Ingebrigtsen" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 13 14:13:29 2022 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 1n7zuy-00038w-HB for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jan 2022 14:13:28 +0100 Original-Received: from localhost ([::1]:34208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7zux-0006Ck-7n for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jan 2022 08:13:27 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7zuY-0006Ae-9a for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 08:13:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39329) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n7zuX-0001RW-Nq for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 08:13:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n7zuX-0006eD-Hg for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 08:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Jay Berkenbilt" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Jan 2022 13:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53207 X-GNU-PR-Package: emacs Original-Received: via spool by 53207-submit@debbugs.gnu.org id=B53207.164207952625457 (code B ref 53207); Thu, 13 Jan 2022 13:13:01 +0000 Original-Received: (at 53207) by debbugs.gnu.org; 13 Jan 2022 13:12:06 +0000 Original-Received: from localhost ([127.0.0.1]:60465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7zte-0006cX-DH for submit@debbugs.gnu.org; Thu, 13 Jan 2022 08:12:06 -0500 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:40345) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7ztZ-0006bw-Jj for 53207@debbugs.gnu.org; Thu, 13 Jan 2022 08:12:05 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 96AC23201DB9; Thu, 13 Jan 2022 08:11:55 -0500 (EST) Original-Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Thu, 13 Jan 2022 08:11:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ql.org; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=mvN6z3F2M5H2LqW3pPbIqFLhQ1bG2BY 9YSPiCm2xm2w=; b=pJ7neJj/T2fAbtnFqxIFgYQvRkMO0QEGHCMOd3JJru4L9G1 n5EQ4avCkqTJRm05OGsV93SAuZ3YeDUBb0RXaDTrUpMVvTb9g12yPq0kY5dJ9Sfb 8ouV2JBD0xeh6gyeJa/O1xX/1I1eIesw37ELBQ7/FQl35ShSDpUW1ctDTq0sqadZ WW7AOD9E444oDetatVwFqpXtQZX/BwPqW9AvCrGso1glkH3layiVuA3dpJvgoIsZ dX7gs5CYW9S2kg7anqltuTjy+LM7hkHDGRSMUXaMJJ/XiRrFsQIhebBZfyeqlCJr mFhfB2s7+ODivY3BgvM0gdBZyiDlIaXwR6kZjng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mvN6z3 F2M5H2LqW3pPbIqFLhQ1bG2BY9YSPiCm2xm2w=; b=L3u7/GnMa98RFV4ynozf1a pVZrvrB3sUD5GgCcIcnBwi64CmEarF9LUiWo9tDj3QNMnI1kxfF4taJaez+0946N 1aZFCPeXUKKWhydjPWvtmNJnx0C2DUuqxZks+g7Uk10u3YsEWPK0zJ8CybBm2fio dadetw+jkqaWVX5jb6zCCjgrUOE8nPZqJcymA318rNqUtqKPLBmJ8DHKqvP0TjEz Xcr6bpPm0uckm0Dh0Pspv4+phbDn5aMoGVUAs2tIzwkBiB+0NxT0ZLhq+fTclKxO l1Be4yBrPN3KavFrxvJ2VP12CiIvYmOsdNXPB6uz4rCTmeSq8cS4xRI1QqQsuGLA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdefgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedflfgrhicu uegvrhhkvghnsghilhhtfdcuoegvjhgssehqlhdrohhrgheqnecuggftrfgrthhtvghrnh ephedtvefhfedvfffgieefudehfefhudfhgeffgffftdevleffhedvvdehjeffueeknecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghjsgesqh hlrdhorhhg X-ME-Proxy: Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id B4D74F60075; Thu, 13 Jan 2022 08:11:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <83sftr3nyx.fsf@gnu.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" Xref: news.gmane.io gmane.emacs.bugs:224103 Archived-At: On Thu, Jan 13, 2022, at 5:54 AM, Eli Zaretskii wrote: > > From: Glenn Morris > > Date: Wed, 12 Jan 2022 13:13:40 -0500 > > Cc: michael.albinus@gmx.de, 53207@debbugs.gnu.org > > > > Probably a consequence of 9ce6541ac9, specifically: > > > > * src/filelock.c (lock_file): Don't check create_lockfiles. > > Actually, the more relevant part is this: > > (Flock_file): Check create_lockfiles. > > which did > > - CHECK_STRING (file); > - lock_file (file); > +#ifndef MSDOS > + /* Don't do locking if the user has opted out. */ > + if (create_lockfiles) > + { > + CHECK_STRING (file); > + lock_file (file); > + } > +#endif /* MSDOS */ > > > which would seem to mean that ask-user-about-supersession-threat > > is no longer called when create-lockfiles is nil. > > Was this intentional? > > Michael, can you please chime in? The long discussion we had back > then doesn't seem to mention this aspect, or maybe I'm missing > something? > > We should either document this change (if we think what we have now is > the intended behavior), or we should move the call to > userlock--ask-user-about-supersession-threat into Flock_file if it's > unintended. > > Personally, I prefer the former, since lock_file accesses the lock > file, which doesn't make a lot of sense if the user opted out of the > feature. But that's me. For my edification, can you explain how the 27.2 behavior of noticing when a file's contents had changed immediately is not adequate without lockfiles? Is it that it doesn't work on some platforms, it doesn't work reliably with a network file system, etc.? It seems to me that there are two separate issues here. A lock file would enable you to immediately notice if a user on a *different system* is in the process of editing a file and has unsaved changes. On the other hand, the other behavior I'm talking about allows you to notice immediately when you begin editing if the file on disk has become out of sync with the buffer contents. These seem like two different things, both of which are valuable. I can't see how you would ever want to disable noticing if the file's contents on disk differ from the buffer, but if you never edit files with emacs on a multi-user system, then I don't see why you would care about lockfiles. All that said, I'm perfectly happy for my own purposes to set lock-file-name-transforms...I'm just trying to contribute a fresh, outside perspective (from someone who has used emacs for over 30 years and has a made a career of software development, including open source software) to the discussion. I trust that everyone is aware of the issue and will come to a good resolution. Thanks! I'm eager to hear the other opinions, even though I have no "vote" in the outcome.