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.