From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#53207: 28.0.91; create-lockfiles nil breaks file change detection Date: Thu, 13 Jan 2022 14:24:03 +0100 Message-ID: References: <509ddd0f-589c-45b0-9b60-5820f4c1d716@www.fastmail.com> <83sftr3nyx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10307"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Glenn Morris , Michael Albinus , Lars Ingebrigtsen , 53207@debbugs.gnu.org To: Jay Berkenbilt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 13 14:28:43 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 1n809j-0002U5-KH for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jan 2022 14:28:43 +0100 Original-Received: from localhost ([::1]:48442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n809i-0000ea-Hv for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jan 2022 08:28:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n806N-0006Jc-QF for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 08:25:17 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39358) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n806B-0003S5-4y for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 08:25:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n806B-00071k-2n for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 08:25:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Jan 2022 13:25:03 +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.164208026126925 (code B ref 53207); Thu, 13 Jan 2022 13:25:03 +0000 Original-Received: (at 53207) by debbugs.gnu.org; 13 Jan 2022 13:24:21 +0000 Original-Received: from localhost ([127.0.0.1]:60490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n805V-00070A-0Q for submit@debbugs.gnu.org; Thu, 13 Jan 2022 08:24:21 -0500 Original-Received: from mail-oi1-f172.google.com ([209.85.167.172]:43616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n805T-0006zv-Lo for 53207@debbugs.gnu.org; Thu, 13 Jan 2022 08:24:20 -0500 Original-Received: by mail-oi1-f172.google.com with SMTP id s22so7576365oie.10 for <53207@debbugs.gnu.org>; Thu, 13 Jan 2022 05:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6juimsxcmoSZrtliSxkI+7ucMr/5ZTjxPu98dadV8q0=; b=TCb5fvPGlwY9Q+KXPB/ok8gbXMLENSCUSq+7oKk9AUQRlPO5dIUYoTBjrDxmid/HRo sQz5G9hkTN6UbP9eiRZ8xmPjGy/4VsAJuV59ZCFZneogDL0dYW0ZFXRk8mJvmtNruJBS N2o9fxY5uHGiYniv8OmmGsqMww9zFqCQulTVcoIV/UJoRlO6oHj64f+ewI7RW4OyYV0l +9y0RWu5gla2rMAaARcO4oBYjC6KyXp17ZChP+m1Snjda5hPkmOFYgmqoZLE+kjIwxrL E83+iOHBcY1mj4ZAiUm68TKb8oulBH77caTAdEv8/zR+OhDOxmfdo2uTwysHuZ58dENG HxcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6juimsxcmoSZrtliSxkI+7ucMr/5ZTjxPu98dadV8q0=; b=BknwbL089UDDdVJiWE7dm+p2VOPuMfPgprt+L3D4a71uSDrdsAO19IvAe3Z1uI6pbW trSNiFxxKewR0t6c6rgjJQi2DmQmFU+lGpjb8w9wDBBvWJ0DdAZaN2fdWsLR1XR/yx0s kwYlW4d6KOrivXtddI+m79URYWBBXBt/UjKTWfjWL8R1/Yb9QAePGhv+pRCuoIUKyLMX 84g1kFauAD4QRkoMYI5FS+sgKhrrPZeXTpJfYEvSp+0pvNVYvPLHv1uPAyXOADvR1Oa5 yD4wPVhJtHLjlqrxXOqAFLKFj8x3Aoo5qzdrGGwlOUSD+7yukVRZMAXNOnzNgIxdBKpm 7F3A== X-Gm-Message-State: AOAM53123tYokNgV9nPBH51mrQPk4/gY5L1OAg1hsTeYp13UiafpsMLn Q5n2e9MzLE1UPqSrDT9Vw95yxQTzPHY6swawsrg= X-Google-Smtp-Source: ABdhPJx044qRjAqKfXydHZ1DENjmXtWG4HKK51ex8oTGJwk96pUFOKzfqX2QMD9rGCq0ocPXwbOqkcDiY+uI0DoZFXo= X-Received: by 2002:aca:1c03:: with SMTP id c3mr3180757oic.158.1642080254057; Thu, 13 Jan 2022 05:24:14 -0800 (PST) In-Reply-To: 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:224106 Archived-At: Am Do., 13. Jan. 2022 um 14:13 Uhr schrieb Jay Berkenbilt : > > > > 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. I fully agree.