[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.
bug#53207: 28.0.91; create-lockfiles nil breaks file change detection, Glenn Morris, 2022/01/12