From: Nate Parsons <parsons.nate@gmail.com>
Date: Thu, 30 Sep 2010 21:10:52 GMT
Subject: Re: git .lock file error
Message-ID: <AANLkTinFJ5rSA7Om0ZxhuqzQiqEDvJ+JoEQFpz=NDvxE@mail.gmail.com>
In-Reply-To: <7vbp7fhtt0.fsf@alter.siamese.dyndns.org>

On Thu, Sep 30, 2010 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> > FWIW I think this is more readable, but maybe we want to retry on all
> > platforms:
> >
> >     my $fh;
> >     if ($^O eq 'MSWin32' or $^O eq 'cygwin') {
> >         # Try 10 times to open our lock file, in case Windows is lagging
> >         for my $try (1..10) {
> >             sysopen($fh, $db_lock, O_RDWR | O_CREAT);
> >             last if $fh;
> >         }
> >     } else {
> >         sysopen($fh, $db_lock, O_RDWR | O_CREAT);
> >     }
> >
> >     warn "Couldnt open $db_lock: $!\n" unless $fh;'

I agree that this is more readable, although I don't think there needs
to be separate code sections for each OS. If it's a good OS, it will
only loop once. You would want to die or croak instead of warn,
though. It needs the lock to continue, right?

> What exactly does "Windows is lagging" mean in the above?
>
> Why does sysopen() randomly fail and why does it succeed (sometimes) when
> it immediately gets retried with the same argument?  Is this a shared lock
> and is used by some other processes that drive git?  Why does the issue
> manifest only on Windows?  If there are competing processes, wouldn't it
> exacerbate the situation to run a tight loop to try grabbing the lock
> without waiting, like the above patch does?

All very good questions, and I don't know most of the answers. I know
that sysopen() is just a thin wrapper around the 'open' system call,
so the problem has to be with Windows somehow. It probably doesn't
happen with other OSes because they're better at files :P

I have verified (to the best of my ability) that this problem happens
even when TortoiseGit is not running, and I don't have cheetah
installed, and there are no other 'git.exe's running. I considered
putting some sort of sleep() in there, but since it worked so well
without the sleep (it only retried once at most). Fetching multiple
revisions is slow anyways, so I don't think a 2-second wait would
hurt, though.

-Nate