Re: git .lock file error

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Oct 1, 2010, 01:59 UTC
Message-ID: <AANLkTi=ZFb4T+RwT+kkccX0jtyQZxs71eJajSX7KQb+h@mail.gmail.com>
In-Reply-To: <AANLkTik2HtyVGz6xFb_VmCh1gSAA_vwpUXhytHFzgCwa@mail.gmail.com>

On Fri, Oct 1, 2010 at 2:54 AM, Nate Parsons <parsons.nate@gmail.com> wrote:

Show 14 quoted lines

> On Thu, Sep 30, 2010 at 7:45 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>
>> Are you running some anti-virus, or from a Dropbox-folder (or
>> something similar)? If so, these applications tend to open files for a
>> short while and then release the file handle. This can some times
>> cause race conditions with other software, like Git.
>>
>> I haven't looked into this particular code-path for what kind of
>> hazards might be, but this sounds very much like one such case to me.
>
> Any of these things are possible. As much as I'd like to find the root cause
> of this problem, isn't making Git more robust a good thing in general?
> Finding every program that could conflict with Git and
> disabling/uninstalling it isn't really a good long term solution, I think.

While making Git more robust is certainly a worthwhile goal, adding retry-loops around any timing-sensitive code without finding out exactly what went wrong is just cargo-cult programming.

I don't think I've ever seen such a breakage with open(..., O_CREAT) before, so I'm sceptical.