From: Ævar Arnfjörð Bjarmason Date: Thu, 30 Sep 2010 21:16:47 GMT Subject: Re: git .lock file error Message-ID: In-Reply-To: On Thu, Sep 30, 2010 at 21:10, Nate Parsons wrote: > On Thu, Sep 30, 2010 at 4:15 PM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason 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? Yes, right. Meant to write croak() not warn() there. >> 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. Maybe this has to do with our assumptions about being on a POSIX filesystem, doesn't Windows have different semantics if two processes open the same file, or something? Blah, I don't know. I'm about as clueless when it comes to Windows as VMS :)