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: "N. Jackson" <njackson <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 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: Sat, 15 Mar 2025 14:40:00 +0000

At 15:16 +0200 on Saturday 2025-03-15, Eli Zaretskii wrote:

>> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> Cc: njackson <at> posteo.net, 75209 <at> debbugs.gnu.org
>> Date: Sat, 15 Mar 2025 12:55:22 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Could the code which writes the file do it in atomic fashion,
>> > i.e. write a temporary file, then rename the original file, then move
>> > the new to the original's name, then delete the original file?
>> >
>> > (On Posix filesystems moving a file to the original name is an atomic
>> > operation, but not on MS-Windows, which is why I suggest a slightly
>> > more complicated procedure.)
>> 
>> See the attached diff.
>> It should be applied on top of previous patches (or on top of the latest
>> Org main).
>
> Thanks, I hope the OP could test this and tell if it makes the problem
> go away for good.

I have applied the new patch and will report back.

I don't think it will help as I only have GNU/Linux systems at the
moment and I think on such systems the earlier patch already made
the write atomic.

I think what is needed is for the read to be atomic.  I might be
completely wrong, but what it seems is happening is that one
instance of Emacs starts a read and reads the first part of the
existing file, then the other instance of Emacs writes the file
(atomically), and then the first instance continues its read,
getting the end of the new file.  So it gets the beginning of one
version of the file and the end of another.

Oughtn't there to be some sort locking mechanism so that the
instance doing the read can lock the file and then the instance that
is about to write the file can see that it shouldn't write it then
and wait until the lock is cleared -- or something along those
lines?

Previous Next

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