GNU bug report logs -
#53207
28.0.91; create-lockfiles nil breaks file change detection
Previous Next
Reported by: "Jay Berkenbilt" <ejb <at> ql.org>
Date: Wed, 12 Jan 2022 14:31:02 UTC
Severity: normal
Found in version 28.0.91
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#53207: 28.0.91; create-lockfiles nil breaks file change detection
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 53207 <at> debbugs.gnu.org.
--
53207: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=53207
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Version 28.1
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi,
>> I've pushed ddba3c3dba to the emacs-28 branch. Tested with
>>
>> --8<---------------cut here---------------start------------->8---
>> # make -C test files-tests filelock-tests tramp-tests SELECTOR='"lock"'
>> --8<---------------cut here---------------end--------------->8---
>>
>> for regression. I've tested also the recipe of the OP, it works now as
>> expected (like in Emacs 27.2).
I've added also a new test filelock-tests-detect-external-change on the
master branch, which checks the scenario of this bug. I haven't done
this for the emacs-28 branch, because it would need a slightly different
implementation. Doing the test on the master branch shall suffice, I believe.
>> The recipe of the OP does not work yet for remote files. I'll continue
>> to fix it, but this shouldn't stall the Emacs 28 release, because the
>> regression tests work also for them. I'll keep the bug open, until this
>> remote case has been fixed, too.
>
> Agreed.
Implementation for Tramp, plus a Tramp specific new test, has also been
pushed to the master branch. This is also kept in Tramp's
branch-2-5-stable branch, which means that it will appear with the next
Tramp ELPA package 2.5.2.2, and it will be merged to the emacs-28 branch
after the Emacs 28.1 release.
Closing the bug.
Best regards, Michael.
[Message part 3 (message/rfc822, inline)]
X-Debbugs-CC: ejb <at> ql.org
This bug is reproducible with emacs -Q.
emacs 28.0.91 and emacs-27.2, with -Q, behave identically and correctly in the following scenario:
* outside of emacs: rm /tmp/a; echo one > /tmp/a
* In a fresh emacs -Q, C-x C-f /tmp/a
* outside of emacs: touch /tmp/a
* In /tmp/a in emacs, it is possible to edit the file freely and save, which is correct since the contents have not changed
* In /tmp/a in emacs, save any changes
* outside of emacs: echo test >> /tmp/a
* In /tmp/a in emacs: try editing and get an immediate prompt that the file has changed.
With emacs 27.2, (setq create-lockfiles nil) does not change the above behavior.
With emacs 28.0.91, (setq create-lockfiles nil) results in the following changes in behavior:
* outside of emacs: rm /tmp/a; echo one > /tmp/a
* In a fresh emacs -Q, C-x C-f /tmp/a
* outside of emacs: touch /tmp/a
* In /tmp/a in emacs, it is possible to edit the file freely, but **SAVING THE FILE RESULTS IN A PROMPT** (a has changed since visited or saved...) even though the *contents* of the file have not changed (only its modification time)
* Say no to the prompt and M-x revert-buffer, accepting the prompt to revert the modified buffer
* outside of emacs: echo test >> /tmp/a
* In /tmp/a in emacs: try editing. **NO PROMPT IS GIVEN; EDITING CAN BE DONE FREELY**
* Try to save the file. Get the "a has changed since visited or saved" prompt at this time
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.
I saw 'lock-file-name-transforms' in NEWS. I disable create-lockfiles because I never run emacs on a multi-user system with my default settings, and the dangling symlinks confuse too many systems. It may be that, if emacs-major-version is >= 28, I can use lock-file-name-transforms to cause lock files to save in a separate directory, but I find that I don't need lockfiles at all with the default behavior of emacs 27 and 28 regarding change detection, at least my on Ubuntu platform.
Is this change intentional? If so, can I configure something to go back to the old behavior? It seems like a bug to me -- I don't see why create-lockfiles should have anything to do with this behavior, and it did not in 27.2. I've been running gnu emacs since version 18 in 1987 and have seen the evolution of lock files over time. I was euphoric when emacs started being able to notice when an update to a file's modification time didn't change its contents. It makes it so much easier to do things like git rebase, which I do many times a day. Thanks.
The text below came from M-x report-emacs-bug on emacs-28.0.91 -Q
In GNU Emacs 28.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
of 2022-01-12 built on jblin
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.3 LTS
Configured using:
'configure --prefix=/usr/local/emacs-28.0.91'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 51426 5400)
(symbols 48 6608 1)
(strings 32 18372 1964)
(string-bytes 1 610917)
(vectors 16 14475)
(vector-slots 8 191331 9434)
(floats 8 21 35)
(intervals 56 200 0)
(buffers 992 10))
This bug report was last modified 3 years and 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.