Re: reftable: new ref storage format
- Date: Sun, 16 Jul 2017 12:10:29 +0200
- From: Johannes Sixt <j6t@xxxxxxxx>
- Subject: Re: reftable: new ref storage format
Am 16.07.2017 um 12:03 schrieb Jeff King:
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
Yes, I think so, too. The pointers make things so much simpler.
I assume that's more or less how pack deletion works on Windows.