bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jay Berkenbilt
Subject: bug#53207: 28.0.91; create-lockfiles nil breaks file change detection
Date: Wed, 12 Jan 2022 15:07:32 -0500
User-agent: Cyrus-JMAP/3.5.0-alpha0-4569-g891f756243-fm-20220111.001-g891f7562


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@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]