From: Jeff King <peff@peff.net>
Date: Sun, 16 Jul 2017 10:03:21 GMT
Subject: Re: reftable: new ref storage format
Message-ID: <20170716100321.3jj4pdz7jqoa3dr4@sigill.intra.peff.net>
In-Reply-To: <4dbe06d0-9a65-7bf5-eb82-6371d9ad7e9b@kdbg.org>

On Sun, Jul 16, 2017 at 10:07:57AM +0200, Johannes Sixt wrote:

> Am 14.07.2017 um 22:08 schrieb Jeff King:
> > The implementation on this doesn't seem overly complex. My main concerns
> > are what we're asking from the filesystem in terms of atomicity, and
> > what possible races there are.
> 
> One of the failure modes is that on Windows a file cannot be deleted while
> it is open in any process. It can happen that a compacting updater wants to
> remove a reftable file that is still open in a reader.

Good point. I think the explicit pointers I mentioned are an improvement
there, because a compacting updater _can_ leave the file in place if the
delete fails (and later, another compaction can clean up cruft that was
left).

I assume that's more or less how pack deletion works on Windows.

-Peff