GNU bug report logs - #66993
[PATCH] project.el: avoid asking user about project-list-file lock

Previous Next

Full log

Message #35 received at 66993 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 66993 <at> debbugs.gnu.org
Subject: Re: bug#66993: [PATCH] project.el: avoid asking user about
 project-list-file lock
Date: Wed, 08 Nov 2023 09:52:16 -0500

Michael Albinus <michael.albinus <at> gmx.de> writes:
> Spencer Baugh <sbaugh <at> janestreet.com> writes:
>
> Hi Spencer,
>
>> If a user has multiple Emacs instances open using one or more of these
>> features, it's fairly easy for both of the Emacs instances to see a
>> new project at the same time.  In that case, they'll both call
>> project--write-project-list at the same time, which will clash and run
>> ask-user-about-lock.  This will happen frequently if the user is often
>> looking at new projects.
>>
>> There's no correct answer the user can give to ask-user-about-lock:
>> either way, one of the Emacs instances will have its project-list-file
>> update lost.  So let's not even bother prompting the user: just do
>> nothing if project-list-file is currently locked.
>
> If you don't care about locking project-list-file, let-bind
> create-lockfiles to nil while writing project-list-file.

Hm, I think that could result in two writes clobbering each other in a
way that creates an invalidly formatted file.  This would happen if
e.g. there were two concurrent write-regions that got interleaved like:

1. write-region(A) starts and writes first half
2. write-region(B) starts and completes
3. write-region(A) writes second half

Then it would be some combination of A and B, which might not be validly
formatted.  From a brief look at the write-region implementation, this
is possible.  (The thing that would make this impossible is if
write-region wrote into a tempfile and then renamed it on top of the
destination.  Instead write-region just writes directly into the file,
opening it with O_TRUNC.)

It's not very likely, but if the lock is conflicting at all and the
project list is large then this will probably happen eventually.

Previous Next

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