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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 27 Jan 2022 19:19:06 +0200

> Date: Sat, 15 Jan 2022 11:23:58 +0200
> From: Eli Zaretskii <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> 
> > From: Lars Ingebrigtsen <[email-masked]>
> > Cc: Michael Albinus <[email-masked]>,  "Jay Berkenbilt"
> >  <[email-masked]>,  "Eli Zaretskii" <[email-masked]>,  [email-masked]
> > Date: Sat, 15 Jan 2022 09:06:17 +0100
> > 
> > Glenn Morris <[email-masked]> writes:
> > 
> > > Was it functionally necessary for the addition of lock file transforms
> > > to break the create-lockfiles nil case? If not, why isn't restoring the
> > > functionality being considered?
> > 
> > Oh, is this a fallout from introducing `lock-file-name-transforms'?
> 
> No, I think this change was introduced by support for locking remote
> files.

Lars, what shall we do about this bug report?  Should we document the
current behavior, or should we move the call to
userlock--ask-user-about-supersession-threat out of Flock_file?  This
should be resolved before the next pretest, I think.