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

[Michael Albinus]

"Jay Berkenbilt" <ejb@ql.org> writes:

Hi Jay,

> On Thu, Jan 13, 2022, at 9:02 AM, Eli Zaretskii wrote:
>> > Date: Thu, 13 Jan 2022 08:11:34 -0500
>> > From: "Jay Berkenbilt" <ejb@ql.org>
>> > Cc: 53207@debbugs.gnu.org
>> > 
>> > 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?
>> 
>> First, Emacs 27 wasn't looking at the file's contents, it was looking
>> at the file's modification time.
>
> My original recipe for reproducing the issue demonstrated that, after
> "touch file", you can continue editing freely and save, but after
> changing the contents, you can't. I don't remember when this first
> changed, maybe emacs 27 or 26. For ages before that, it was
> modification time. I remember noticing when updating the modtime
> without changing the content stopped triggering that. I was delighted.
>
> It is definitely the case that just updating the modification time on
> emacs 27.2 does not trigger this. You can try it. In emacs -Q, edit a
> file and save. From the shell, touch the file. No continue editing the
> file and save again. No warning. At least this is the case on my
> Ubuntu Linux 20.04 system with emacs compiled from source.

Same here. In lock_file of Emacs 27, there is the check

--8<---------------cut here---------------start------------->8---
    if (!NILP (subject_buf)
        && NILP (Fverify_visited_file_modtime (subject_buf))
        && !NILP (Ffile_exists_p (fn)))
      call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
--8<---------------cut here---------------end--------------->8---

It checks the file modification time. But then, if changed, it calls
userlock--ask-user-about-supersession-threat, which also checks the file
contents before warning. Therefore, a simple touch doesn't trigger the
user question.

>> > 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.
>> 
>> No, it also works when the same user on the same system edited the
>> file from another Emacs session.  That is a valid use case: some
>> people start more than a single Emacs session on the same system.
>
> Granted. Of course it doesn't protect against another very common use
> case, which is people opening the same file in emacs and
> simultaneously in something like VS Code or another IDE. I know
> developers that work this way day in and day out -- they use emacs for
> most of their editing but hop over to an IDE to take advantage of
> project-wide integrations, better test integration, a more advanced
> debugger, or better out-of-the-box functionality with their
> programming language or environment of choice. So lock files remain a
> solution that only works in an emacs-only environment, while noticing
> that the file's modification time has changed is universal, and
> noticing that a file's content has changed is a great advancement over
> just noticing modtime since it allows for workflows like git rebase.
>
>> > 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.
>> 
>> That part is done when you save the buffer.  It is unaffected by
>> create-lockfiles.
>
> It is also done when you start editing a buffer, as shown in my original
> message. Really. Try it.

Sure. That's because there's no visited file modification time yet for
that buffer.

In Emacs 28, the check above has been extended to

--8<---------------cut here---------------start------------->8---
  if (!NILP (subject_buf)
      && NILP (Fverify_visited_file_modtime (subject_buf))
      && !NILP (Ffile_exists_p (fn))
      && current_lock_owner (NULL, lfname) != I_OWN_IT)
    call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
--8<---------------cut here---------------end--------------->8---

So it checks also the owner of the lock file. This makes only sense, if
create-lockfiles is non-nil; otherwise there is no lock file owner ...

I agree with Eli, that the current behavior in Emacs 28 is
consistent. Since this is an incompatible change, we shall document
it. The Emacs 28 manual says

--8<---------------cut here---------------start------------->8---
   You can prevent the creation of lock files by setting the variable
‘create-lockfiles’ to ‘nil’.  *Caution:* by doing so you will lose the
benefits that this feature provides.
--8<---------------cut here---------------end--------------->8---

Maybe it shall be more explicit saying, that also detection of changing
the modification time is lost when create-lockfiles is nil.

etc/NEWS is silent about this, it should explain this subtle change as well.

Best regards, Michael.