bug#53207: 28.0.91; create-lockfiles nil breaks file change detection

[Philipp Stephani]

Am Do., 13. Jan. 2022 um 14:13 Uhr schrieb Jay Berkenbilt <ejb@ql.org>:
>
>
>
> On Thu, Jan 13, 2022, at 5:54 AM, Eli Zaretskii wrote:
> > > From: Glenn Morris <rgm@gnu.org>
> > > 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.