Re: Race condition in git-bundle(1) create when ref is updated while running
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Feb 12, 2024, 07:19 UTC
- Message-ID
- <ZcnGkFI5IiylfGiH@tanuki>
- In-Reply-To
- <xmqq5xyxh6zp.fsf@gitster.g>
On Fri, Feb 09, 2024 at 09:39:38AM -0800, Junio C Hamano wrote:
Show 14 quoted lines
> Toon Claes <toon@iotcl.com> writes:
>
> > I discovered a bug in git-bundle(1) create. There is a race condition
> > happening when a ref gets updated while the bundle creation process is
> > running.
>
> "--all" that tells "traverse from the tip of all the refs" to any
> rev-list family of commands (like log and bundle) eventually boils
> down to opendir("refs/...") followed by readdir(), and if somebody
> creates or deletes files while you are reading in such a loop,
> readdir() may appear to skip an entry, which is understandable.
> Even "git for-each-ref" would race with a ref update (which involves
> removing a file and then creating another file at the same path), I
> would think. IOW, I do not think this is limited to "git bundle".Yeah, it's unfortunately a general issue with the "files" backend and nothing that can easily be solved there. The only answer I can provide in this context is that the "reftable" backend will fix it because it enables consistent reads -- sorry for this shameless plug.
Patrick