Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains

From: Eli Zaretskii <[email-masked]>
Date: Mon, 12 Jul 2021 20:30:21 +0300

> From: Michael Albinus <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Mon, 12 Jul 2021 16:37:45 +0200
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> Hi Eli,
> 
> >> Lars Ingebrigtsen <[email-masked]> writes:
> >>
> >> >> Until now, there are no file locks for remote files at all. I thought
> >> >> disabling it for remote files would be requested by some users for
> >> >> backward compatibility.
> >> >
> >> > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems
> >> > like the natural way to implement it.
> >>
> >> And now? You and Eli disagree in this point, and I don't know what to do.
> >
> > Which disagreement between us leaves you at an impasse?  If there is
> > indeed such a disagreement, maybe we could find a compromise which
> > will allow some way forward.
> 
> Lars agrees my proposal to use lock-file-name-transforms for disabling
> file locks. You did argue against.

Are we talking about disabling remote locks by default?  If so, how
about disabling them via a more user-friendly option?  It strikes me
as weird and un-intuitive to _disable_ something via a "transform"
function.  And it will definitely be more complex to set up such a
"transform" function than just use a boolean flag.