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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 13 Jan 2022 08:43:14 +0200

> Date: Wed, 12 Jan 2022 16:35:15 -0500
> From: "Jay Berkenbilt" <[email-masked]>
> Cc: [email-masked]
> 
> > > > My suggestion is to stop setting create-lockfiles to a nil value.  Why
> > > > is the non-nil value a problem?
> > > 
> > > Emacs lockfiles are dangling symbolic links. Some tools and systems don't
> > > like those.
> > 
> > Isn't that the reason we introduced lock-file-name-transforms?
> 
> Perhaps so, but this misses the point.

My point was to say that if you want collision detection, you should
turn on create-lockfiles.  You said this could cause problems with
some tools, and I then pointed out that Emacs 28 has a new feature to
help you solve that side effect, so that you could use locking again.

> I am pointing out at there is an undocumented,
> perhaps undesirable change of behavior that needs to be either fixed or documented.

I understand, but that's a separate, albeit related, issue.  I was
trying to help you to get collision detection back.  Your original
report seemed to ask how to do that, so I tried to answer that part.

> If the change of behavior is intentional, then it should be documented.

We are discussing this, and will document if that's the conclusion.

> It just seems strange that emacs is perfectly capable of detecting when a file was changed
> outside of emacs without a lockfile but doesn't do this check if it's not also creating lockfiles.

Once again, this is not about the lockfiles, this is about the entire
feature of detection of editing collisions.  The variable's name is a
misnomer.