GNU bug report logs - #75209
30.0.93; Emacs reader failed to read data in "/home/nlj/.cache/org-persist/gc-lock.eld"

Previous Next

Full log

View this message in rfc822 format

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: "N. Jackson" <njackson <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75209 <at> debbugs.gnu.org
Subject: bug#75209: 30.0.93; Emacs reader failed to read data in "/home/nlj/.cache/org-persist/gc-lock.eld"
Date: Fri, 25 Apr 2025 17:14:06 +0000

"N. Jackson" <njackson <at> posteo.net> writes:

>>>> -  (let ((write-region-inhibit-fsync t)
>>>> +  (let ((write-region-inhibit-fsync nil)
>>>>          ;; We set UTF-8 here and in `org-persist--read-elisp-file'
>>>>          ;; to avoid the overhead from `find-auto-coding'.
>>>>          (coding-system-for-write 'emacs-internal)
>>>
>>> I will test this diff and report back.
>>
>> It has been a while since the last update in this thread.
>> Does it mean that the diff fixed the problem for good?
>
> I haven't seen the bug since installing the change quoted above that
> let binds `write-region-inhibit-fsync' to nil.
>
> Unfortunately, however, there is a confounding factor because around
> the same time as I made this change, I switched from mainly using a
> very slow desktop system to using a considerably faster laptop.

Hmm. Then, may you go back to no patches at all?
If we find that `write-region-inhibit-fsync' has undesired side effects,
it will be an important piece of information - its default value has
been changed in the whole Emacs recently on the grounds that fsync makes
no difference on modern systems.

> A slight tangent follows about the patch to do the atomic write
> juggle for Windows systems.
> ...
> ...
> After the fix using `make-temp-name' instead of `make-temp-file',
> there are still two problems with the code:
>
> Problem 1. `rename-file' produces an error if the file doesn't exist
> -- which it doesn't the first time the code runs.
>
> Problem 2. Unlike `make-temp-file', `make-temp-name' requires an
> absolute file name otherwise the file ends up in the current
> directory, whatever that happens to be at the time of the write.

True. That was a very approximate patch.
However, I am not sure if that patch will be needed at all. Maybe all
the problems were related to your old system + fsync, for example.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Previous Next

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