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

[Jay Berkenbilt]

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.

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.