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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 31 Dec 2024 21:54:02 +0200

> From: Ihor Radchenko <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>, [email-masked]
> Date: Tue, 31 Dec 2024 19:02:35 +0000
> 
> "N. Jackson" <[email-masked]> writes:
> 
> >> Or, alternatively, C-g in the middle of writing.
> >
> > I use C-g very frequently.  I type `M-x' and then realise I want to
> > do `C-h f' first instead, so I do `C-g' to exit from the M-x prompt.
> > Or I do an isearch and then change my mind (or find and read
> > whatever I was looking for) then I do `C-g' (twice, I think) to exit
> > the isearch and get back to where I started.  Usages like that.
> > From my (probably naive) point of view, if that messes up Org Mode,
> > then Org Mode is doing something wrong.
> 
> That should not be a problem then.
> Reading/writing GC file is done using timer and, AFAIK, Emacs should not
> run timers while you are running a command.

If this happens while the user types some command, then timers could
fire during that typing, since people rarely type fast enough to not
let timers run.

But all this is not relevant, because Emacs binds inhibit-quit to a
non-nil value while it runs the timer function.  So, unless the timer
in question somehow forcibly resets inhibit-quit to nil, C-g should
not be able to interrupt a timer.

> >> gc-lock.eld is a file used to flag that cache dir is being worked
> >> on by multiple emacs instances. GC here refers to
> >> garbage-collecting cache data.
> >
> > I do run multiple (two) instances of Emacs.  One is my normal
> > session where I use Org quite heavily.  The other is my Gnus session
> > in which I never open an Org file and never (as far as I know) use
> > any Org features.
> 
> Gnus may load Org. (AFAIU, it does it when viewing gnus articles)
> 
> Another possible scenario is two Org instances writing to the same file
> at the same time.
> If it is what is happening in your case, your problem may be similar to 
> https://list.orgmode.org/orgmode/[email-masked]/

Can't Org prevent more than one session writing to this file?  We have
file locks which can be used here, I think.