Re: Bug: fatal: Unable to create '.../.git/index.lock': File exists.

From: Duy Nguyen <pclouds@gmail.com>
Date: May 2, 2019, 17:24 UTC
Message-ID: <CACsJy8D7bx46bix_LmGr=xcwsrA=LehXmLmnONLz2w3q6f80vw@mail.gmail.com>
In-Reply-To: <20190502165802.GA19341@sigill.intra.peff.net>

On Thu, May 2, 2019 at 11:58 PM Jeff King <peff@peff.net> wrote:

Show 9 quoted lines

> > I might take a stab at the "wait and try to hold the lock again, doing
> > necessary verification after if needed" idea. It sounds like the right
> > way to go and we haven't had problems with refs doing the same thing
> > (have we?).
>
> No, but it's a bit easier with refs because the locking is just
> atomically checking the lease. I.e., after taking the lock we still say
> "we expected the ref to be at oid XYZ, is it still there?". What's the
> equivalent for an index operation?

That's something for me to find out :)

Show 9 quoted lines

> I think it is more common with the index to take the lock, then while
> holding it read it in fresh (possibly dumping old results), manipulate
> the result, and then write it out. For callers which make sure to
> get a fresh view _after_ taking the lock, they should be OK if taking
> the lock is delayed.
>
> I guess arguably any callers that aren't that careful are already
> broken, since it is a race; any delay-and-retry _could_ have happened as
> "we were too slow to see the initial lock".

I have a feeling that most operations read the index unlocked, manipulate and only lock before writing things out. So yeah it's probably already racy.

We could use the trailing SHA-1 to determine if the index has not changed since last time, but then refresh-only updates would be considered valuable while it's not. Full index comparison is way too expensive (at least with giant repos) to even consider. I think I start to see why nobody has done this...

-- 
Duy