Re: reftable: new ref storage format
- From
Jeff King <peff@peff.net>
- Date
- Jul 16, 2017, 10:03 UTC
- 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:
Show 8 quoted lines
> 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