GNU bug report logs - #53207
28.0.91; create-lockfiles nil breaks file change detection

Previous Next

Full log

Message #17 received at 53207 <at> debbugs.gnu.org (full text, mbox):

From: "Jay Berkenbilt" <ejb <at> ql.org>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 53207 <at> debbugs.gnu.org
Subject: Re: bug#53207: 28.0.91;
 create-lockfiles nil breaks file change detection
Date: Wed, 12 Jan 2022 15:07:32 -0500

On Wed, Jan 12, 2022, at 12:26 PM, Eli Zaretskii wrote:
> > Date: Wed, 12 Jan 2022 09:30:07 -0500
> > From: "Jay Berkenbilt" <ejb <at> ql.org>
> > 
> > Bottom line: in emacs 27.2, setting create-lockfiles to nil does not change the behavior. In emacs 28.0.91, it does. I also noticed this in 28.0.90 but hadn't had time to figure out how to reproduce it without my customizations.
> 
> You seem to assume that create-lockfiles is _only_ about the creation
> of the lockfiles.  But that's not true: the variable is a misnomer,
> and it actually controls the entire functionality of preventing
> editing collisions.  Including the test for the file being modified
> behind Emacs's back.  The doc string says:
> 
>   Non-nil means use lockfiles to avoid editing collisions.

I interpreted this to mean that this was the method of preventing collisions,
as opposed to some other method.

> 
> > Is this change intentional? If so, can I configure something to go
> > back to the old behavior?
> 
> 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. For example, I was working on a learning project to teach myself
modern web development and was using tools that do hot reload, scanning
directories for tests. Every time I started editing, it would pick up the lock file
and give an error. You could make an argument that it is a bug in the tool,
but the cross section of people who live and breathe in emacs and who are
working on front-end web development seems to be very small, and there's
little incentive for them to add code that ignores dangling symbolic links. Most
people consider those to be errors. I get why it's done though -- I have
implemented symlink-based lock files myself since they are easier to make 
atomic, especially when network file systems are in play.

But, from a pragmatic standpoint, I don't need them, and I'd like to turn them off,
and it used to work and no longer does. This is why I'm testing 28 -- to catch
things like this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.