{"thread":{"id":"25094","subject":"git .lock file error","startedAt":"2010-09-13T15:19:30Z","lastAt":"2010-10-01T01:59:48Z","messageCount":10,"participants":["Nate Parsons","Ævar Arnfjörð Bjarmason","Junio C Hamano","Erik Faye-Lund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"150600","messageId":"AANLkTikjwW8jJ3qGCAM=8F_GBxsz9_KoSW0KDGPKhXGQ@mail.gmail.com","threadId":"25094","inReplyTo":null,"subject":"git .lock file error","fromName":"Nate Parsons","fromEmail":"parsons.nate@gmail.com","sentAt":"2010-09-13T15:19:30Z","receivedAt":"2010-09-13T15:19:30Z","isPatch":false,"sender":{"key":"parsons.nate@gmail.com","avatar":"https://gravatar.com/avatar/8fbd472c9e74c6f64c305d4ea09575011b36a7844737f47a36f59086d88646fb?d=mp&s=160"},"body":"Hi everyone,\n\nI'm trying to switch to git, so I apologize in advance for my\nignorance. For this, I'm using cygwin git, version 1.7.1 to talk to a\nsvn server running 1.4.2.\n\nWhen I 'git svn clone' or 'git svn clone; git svn fetch', I sometimes\nrun into the following error.\n> Couldn't open .git/svn/refs/remotes/0.0.0/.rev_map.b8cad480-e46b-48b4-8317-a683ee46c2bd.lock: Device or resource busy\n>  at /usr/lib/git-core/git-svn line 5210\n\nAnd when I 'git svn rebase'\n> Couldn't open .git/svn/refs/remotes/git-svn/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy\n> at /usr/lib/git-core/git-svn line 1528\n\nSometimes the line number is different (578, I think?), but when I\nretry the fetch command, it rebuilds the file corresponding to the\nlockfile, and then continues a little farther before dying again.\n\nWhen I watch the directory in question, I see the lock file appear,\nand then disappearing a short time after the script gives up.\n\nI don't have a series of steps to reproduce the problem, sometimes it\ngoes for an hour, and sometimes for just a few minutes/seconds.\n\nI do have TortoiseGit running my machine, but this issue happens even\nwhen TGitCache.exe is not running. If some other instance of git is\naccessing the repository, I don't know which or how.\n\nThanks,\n-Nate\n"},{"id":"151042","messageId":"AANLkTin+MRkYv7vL7eY+mdWG1vTg-E9pVpU4_QujoxdZ@mail.gmail.com","threadId":"25094","inReplyTo":"AANLkTikjwW8jJ3qGCAM=8F_GBxsz9_KoSW0KDGPKhXGQ@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Nate Parsons","fromEmail":"parsons.nate@gmail.com","sentAt":"2010-09-20T02:42:11Z","receivedAt":"2010-09-20T02:42:11Z","isPatch":false,"sender":{"key":"parsons.nate@gmail.com","avatar":"https://gravatar.com/avatar/8fbd472c9e74c6f64c305d4ea09575011b36a7844737f47a36f59086d88646fb?d=mp&s=160"},"body":"Hello again,\n\nI realized I have git-cheetah running as well, so I killed\nexplorer.exe (the only process using git_shell_ext.exe), and tried\nagain. That's when I noticed that running 'git svn fetch' spawned two\ngit processes and a perl process (which later spawned another perl).\nIs this something that should be happening?\n\nThanks,\n-Nate\n\nOn Mon, Sep 13, 2010 at 11:19 AM, Nate Parsons <parsons.nate@gmail.com> wrote:\n>\n> Hi everyone,\n>\n> I'm trying to switch to git, so I apologize in advance for my\n> ignorance. For this, I'm using cygwin git, version 1.7.1 to talk to a\n> svn server running 1.4.2.\n>\n> When I 'git svn clone' or 'git svn clone; git svn fetch', I sometimes\n> run into the following error.\n> > Couldn't open .git/svn/refs/remotes/0.0.0/.rev_map.b8cad480-e46b-48b4-8317-a683ee46c2bd.lock: Device or resource busy\n> >  at /usr/lib/git-core/git-svn line 5210\n>\n> And when I 'git svn rebase'\n> > Couldn't open .git/svn/refs/remotes/git-svn/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy\n> > at /usr/lib/git-core/git-svn line 1528\n>\n> Sometimes the line number is different (578, I think?), but when I\n> retry the fetch command, it rebuilds the file corresponding to the\n> lockfile, and then continues a little farther before dying again.\n>\n> When I watch the directory in question, I see the lock file appear,\n> and then disappearing a short time after the script gives up.\n>\n> I don't have a series of steps to reproduce the problem, sometimes it\n> goes for an hour, and sometimes for just a few minutes/seconds.\n>\n> I do have TortoiseGit running my machine, but this issue happens even\n> when TGitCache.exe is not running. If some other instance of git is\n> accessing the repository, I don't know which or how.\n>\n> Thanks,\n> -Nate\n"},{"id":"152181","messageId":"AANLkTim2sFCx8qZ-6o4tiugX3a-EBN9T8wuCSWXb5L12@mail.gmail.com","threadId":"25094","inReplyTo":"AANLkTin+MRkYv7vL7eY+mdWG1vTg-E9pVpU4_QujoxdZ@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Nate Parsons","fromEmail":"parsons.nate@gmail.com","sentAt":"2010-09-30T18:00:52Z","receivedAt":"2010-09-30T18:00:52Z","isPatch":false,"sender":{"key":"parsons.nate@gmail.com","avatar":"https://gravatar.com/avatar/8fbd472c9e74c6f64c305d4ea09575011b36a7844737f47a36f59086d88646fb?d=mp&s=160"},"body":"OK, so this is definitely a win32 issue. I believe that the perl\nscript is simply creating .lock files too fast for Windows to keep up.\nSimply trying again fixes the problem for me.\n\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -3676,8 +3676,10 @@ sub rev_map_set {\n \t\t\t\t\t    \"$db => $db_lock ($!)\\n\";\n \t}\n\n-\tsysopen(my $fh, $db_lock, O_RDWR | O_CREAT)\n-\t     or croak \"Couldn't open $db_lock: $!\\n\";\n+   my $fh;\n+   my $tries=10;\n+   for(; !sysopen($fh, $db_lock, O_RDWR | O_CREAT) && $tries>=0; $tries--) { }\n+   if($tries <= 0) { croak \"Couldn't open $db_lock: $!\\n\"; }\n \t$update_ref eq 'reset' ? _rev_map_reset($fh, $rev, $commit) :\n \t\t\t\t _rev_map_set($fh, $rev, $commit);\n \tif ($sync) {\n\nIf this is a reasonable solution, I can go figure out how to properly\nformat a patch to the list.\n\n-Nate\n\nOn Sun, Sep 19, 2010 at 10:42 PM, Nate Parsons <parsons.nate@gmail.com> wrote:\n>\n> Hello again,\n>\n> I realized I have git-cheetah running as well, so I killed\n> explorer.exe (the only process using git_shell_ext.exe), and tried\n> again. That's when I noticed that running 'git svn fetch' spawned two\n> git processes and a perl process (which later spawned another perl).\n> Is this something that should be happening?\n>\n> Thanks,\n> -Nate\n>\n> On Mon, Sep 13, 2010 at 11:19 AM, Nate Parsons <parsons.nate@gmail.com> wrote:\n> >\n> > Hi everyone,\n> >\n> > I'm trying to switch to git, so I apologize in advance for my\n> > ignorance. For this, I'm using cygwin git, version 1.7.1 to talk to a\n> > svn server running 1.4.2.\n> >\n> > When I 'git svn clone' or 'git svn clone; git svn fetch', I sometimes\n> > run into the following error.\n> > > Couldn't open .git/svn/refs/remotes/0.0.0/.rev_map.b8cad480-e46b-48b4-8317-a683ee46c2bd.lock: Device or resource busy\n> > >  at /usr/lib/git-core/git-svn line 5210\n> >\n> > And when I 'git svn rebase'\n> > > Couldn't open .git/svn/refs/remotes/git-svn/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy\n> > > at /usr/lib/git-core/git-svn line 1528\n> >\n> > Sometimes the line number is different (578, I think?), but when I\n> > retry the fetch command, it rebuilds the file corresponding to the\n> > lockfile, and then continues a little farther before dying again.\n> >\n> > When I watch the directory in question, I see the lock file appear,\n> > and then disappearing a short time after the script gives up.\n> >\n> > I don't have a series of steps to reproduce the problem, sometimes it\n> > goes for an hour, and sometimes for just a few minutes/seconds.\n> >\n> > I do have TortoiseGit running my machine, but this issue happens even\n> > when TGitCache.exe is not running. If some other instance of git is\n> > accessing the repository, I don't know which or how.\n> >\n> > Thanks,\n> > -Nate\n"},{"id":"152188","messageId":"AANLkTik364t7WEHOsZcB7FE4Y2gJQNxkXsRvW5guUWCi@mail.gmail.com","threadId":"25094","inReplyTo":"AANLkTim2sFCx8qZ-6o4tiugX3a-EBN9T8wuCSWXb5L12@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-09-30T19:13:02Z","receivedAt":"2010-09-30T19:13:02Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Sep 30, 2010 at 18:00, Nate Parsons <parsons.nate@gmail.com> wrote:\n> OK, so this is definitely a win32 issue. I believe that the perl\n> script is simply creating .lock files too fast for Windows to keep up.\n> Simply trying again fixes the problem for me.\n\nSounds like something that might do with a non-hacky solution, but I\ndon't know what that would be.\n\n> -       sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)\n> -            or croak \"Couldn't open $db_lock: $!\\n\";\n> +   my $fh;\n> +   my $tries=10;\n> +   for(; !sysopen($fh, $db_lock, O_RDWR | O_CREAT) && $tries>=0; $tries--) { }\n> +   if($tries <= 0) { croak \"Couldn't open $db_lock: $!\\n\"; }\n>        $update_ref eq 'reset' ? _rev_map_reset($fh, $rev, $commit) :\n>                                 _rev_map_set($fh, $rev, $commit);\n>        if ($sync) {\n\nFWIW I think this is more readable, but maybe we want to retry on all\nplatforms:\n\n    my $fh;\n    if ($^O eq 'MSWin32' or $^O eq 'cygwin') {\n        # Try 10 times to open our lock file, in case Windows is lagging\n        for my $try (1..10) {\n            sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n            last if $fh;\n        }\n    } else {\n        sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n    }\n\n    warn \"Couldnt open $db_lock: $!\\n\" unless $fh;'\n"},{"id":"152194","messageId":"7vbp7fhtt0.fsf@alter.siamese.dyndns.org","threadId":"25094","inReplyTo":"AANLkTik364t7WEHOsZcB7FE4Y2gJQNxkXsRvW5guUWCi@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-09-30T20:15:23Z","receivedAt":"2010-09-30T20:15:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Thu, Sep 30, 2010 at 18:00, Nate Parsons <parsons.nate@gmail.com> wrote:\n>> OK, so this is definitely a win32 issue. I believe that the perl\n>> script is simply creating .lock files too fast for Windows to keep up.\n>> Simply trying again fixes the problem for me.\n>\n> Sounds like something that might do with a non-hacky solution, but I\n> don't know what that would be.\n>\n> ...\n> FWIW I think this is more readable, but maybe we want to retry on all\n> platforms:\n>\n>     my $fh;\n>     if ($^O eq 'MSWin32' or $^O eq 'cygwin') {\n>         # Try 10 times to open our lock file, in case Windows is lagging\n>         for my $try (1..10) {\n>             sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n>             last if $fh;\n>         }\n>     } else {\n>         sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n>     }\n\nWhat exactly does \"Windows is lagging\" mean in the above?\n\nWhy does sysopen() randomly fail and why does it succeed (sometimes) when\nit immediately gets retried with the same argument?  Is this a shared lock\nand is used by some other processes that drive git?  Why does the issue\nmanifest only on Windows?  If there are competing processes, wouldn't it\nexacerbate the situation to run a tight loop to try grabbing the lock\nwithout waiting, like the above patch does?\n"},{"id":"152197","messageId":"AANLkTinFJ5rSA7Om0ZxhuqzQiqEDvJ+JoEQFpz=NDvxE@mail.gmail.com","threadId":"25094","inReplyTo":"7vbp7fhtt0.fsf@alter.siamese.dyndns.org","subject":"Re: git .lock file error","fromName":"Nate Parsons","fromEmail":"parsons.nate@gmail.com","sentAt":"2010-09-30T21:10:52Z","receivedAt":"2010-09-30T21:10:52Z","isPatch":false,"sender":{"key":"parsons.nate@gmail.com","avatar":"https://gravatar.com/avatar/8fbd472c9e74c6f64c305d4ea09575011b36a7844737f47a36f59086d88646fb?d=mp&s=160"},"body":"On Thu, Sep 30, 2010 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> > FWIW I think this is more readable, but maybe we want to retry on all\n> > platforms:\n> >\n> >     my $fh;\n> >     if ($^O eq 'MSWin32' or $^O eq 'cygwin') {\n> >         # Try 10 times to open our lock file, in case Windows is lagging\n> >         for my $try (1..10) {\n> >             sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n> >             last if $fh;\n> >         }\n> >     } else {\n> >         sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n> >     }\n> >\n> >     warn \"Couldnt open $db_lock: $!\\n\" unless $fh;'\n\nI agree that this is more readable, although I don't think there needs\nto be separate code sections for each OS. If it's a good OS, it will\nonly loop once. You would want to die or croak instead of warn,\nthough. It needs the lock to continue, right?\n\n> What exactly does \"Windows is lagging\" mean in the above?\n>\n> Why does sysopen() randomly fail and why does it succeed (sometimes) when\n> it immediately gets retried with the same argument?  Is this a shared lock\n> and is used by some other processes that drive git?  Why does the issue\n> manifest only on Windows?  If there are competing processes, wouldn't it\n> exacerbate the situation to run a tight loop to try grabbing the lock\n> without waiting, like the above patch does?\n\nAll very good questions, and I don't know most of the answers. I know\nthat sysopen() is just a thin wrapper around the 'open' system call,\nso the problem has to be with Windows somehow. It probably doesn't\nhappen with other OSes because they're better at files :P\n\nI have verified (to the best of my ability) that this problem happens\neven when TortoiseGit is not running, and I don't have cheetah\ninstalled, and there are no other 'git.exe's running. I considered\nputting some sort of sleep() in there, but since it worked so well\nwithout the sleep (it only retried once at most). Fetching multiple\nrevisions is slow anyways, so I don't think a 2-second wait would\nhurt, though.\n\n-Nate\n"},{"id":"152198","messageId":"AANLkTi=H0vhNJTT9uWYXmy=45_wrvb0xwjRSHvAETiAB@mail.gmail.com","threadId":"25094","inReplyTo":"AANLkTinFJ5rSA7Om0ZxhuqzQiqEDvJ+JoEQFpz=NDvxE@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-09-30T21:16:47Z","receivedAt":"2010-09-30T21:16:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Sep 30, 2010 at 21:10, Nate Parsons <parsons.nate@gmail.com> wrote:\n> On Thu, Sep 30, 2010 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>> > FWIW I think this is more readable, but maybe we want to retry on all\n>> > platforms:\n>> >\n>> >     my $fh;\n>> >     if ($^O eq 'MSWin32' or $^O eq 'cygwin') {\n>> >         # Try 10 times to open our lock file, in case Windows is lagging\n>> >         for my $try (1..10) {\n>> >             sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n>> >             last if $fh;\n>> >         }\n>> >     } else {\n>> >         sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n>> >     }\n>> >\n>> >     warn \"Couldnt open $db_lock: $!\\n\" unless $fh;'\n>\n> I agree that this is more readable, although I don't think there needs\n> to be separate code sections for each OS. If it's a good OS, it will\n> only loop once. You would want to die or croak instead of warn,\n> though. It needs the lock to continue, right?\n\nYes, right. Meant to write croak() not warn() there.\n\n>> What exactly does \"Windows is lagging\" mean in the above?\n>>\n>> Why does sysopen() randomly fail and why does it succeed (sometimes) when\n>> it immediately gets retried with the same argument?  Is this a shared lock\n>> and is used by some other processes that drive git?  Why does the issue\n>> manifest only on Windows?  If there are competing processes, wouldn't it\n>> exacerbate the situation to run a tight loop to try grabbing the lock\n>> without waiting, like the above patch does?\n>\n> All very good questions, and I don't know most of the answers. I know\n> that sysopen() is just a thin wrapper around the 'open' system call,\n> so the problem has to be with Windows somehow. It probably doesn't\n> happen with other OSes because they're better at files :P\n>\n> I have verified (to the best of my ability) that this problem happens\n> even when TortoiseGit is not running, and I don't have cheetah\n> installed, and there are no other 'git.exe's running. I considered\n> putting some sort of sleep() in there, but since it worked so well\n> without the sleep (it only retried once at most). Fetching multiple\n> revisions is slow anyways, so I don't think a 2-second wait would\n> hurt, though.\n\nMaybe this has to do with our assumptions about being on a POSIX\nfilesystem, doesn't Windows have different semantics if two processes\nopen the same file, or something?\n\nBlah, I don't know. I'm about as clueless when it comes to Windows as\nVMS :)\n"},{"id":"152206","messageId":"AANLkTikV=f1ncAxQ1LWzntnOwiBKMfw_D8Mcuh+wCO3+@mail.gmail.com","threadId":"25094","inReplyTo":"AANLkTinFJ5rSA7Om0ZxhuqzQiqEDvJ+JoEQFpz=NDvxE@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-09-30T23:45:03Z","receivedAt":"2010-09-30T23:45:03Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Sep 30, 2010 at 11:10 PM, Nate Parsons <parsons.nate@gmail.com> wrote:\n> On Thu, Sep 30, 2010 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>> > FWIW I think this is more readable, but maybe we want to retry on all\n>> > platforms:\n>> >\n>> >     my $fh;\n>> >     if ($^O eq 'MSWin32' or $^O eq 'cygwin') {\n>> >         # Try 10 times to open our lock file, in case Windows is lagging\n>> >         for my $try (1..10) {\n>> >             sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n>> >             last if $fh;\n>> >         }\n>> >     } else {\n>> >         sysopen($fh, $db_lock, O_RDWR | O_CREAT);\n>> >     }\n>> >\n>> >     warn \"Couldnt open $db_lock: $!\\n\" unless $fh;'\n>\n> I agree that this is more readable, although I don't think there needs\n> to be separate code sections for each OS. If it's a good OS, it will\n> only loop once. You would want to die or croak instead of warn,\n> though. It needs the lock to continue, right?\n>\n>> What exactly does \"Windows is lagging\" mean in the above?\n>>\n>> Why does sysopen() randomly fail and why does it succeed (sometimes) when\n>> it immediately gets retried with the same argument?  Is this a shared lock\n>> and is used by some other processes that drive git?  Why does the issue\n>> manifest only on Windows?  If there are competing processes, wouldn't it\n>> exacerbate the situation to run a tight loop to try grabbing the lock\n>> without waiting, like the above patch does?\n>\n> All very good questions, and I don't know most of the answers. I know\n> that sysopen() is just a thin wrapper around the 'open' system call,\n> so the problem has to be with Windows somehow. It probably doesn't\n> happen with other OSes because they're better at files :P\n>\n> I have verified (to the best of my ability) that this problem happens\n> even when TortoiseGit is not running, and I don't have cheetah\n> installed, and there are no other 'git.exe's running.\n\nAre you running some anti-virus, or from a Dropbox-folder (or\nsomething similar)? If so, these applications tend to open files for a\nshort while and then release the file handle. This can some times\ncause race conditions with other software, like Git.\n\nI haven't looked into this particular code-path for what kind of\nhazards might be, but this sounds very much like one such case to me.\n"},{"id":"152210","messageId":"AANLkTi=eMt_OduJ8d=5mhhnt+q-Mpb8b1iimt_0bws3f@mail.gmail.com","threadId":"25094","inReplyTo":"AANLkTikV=f1ncAxQ1LWzntnOwiBKMfw_D8Mcuh+wCO3+@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Nate Parsons","fromEmail":"parsons.nate@gmail.com","sentAt":"2010-10-01T00:57:20Z","receivedAt":"2010-10-01T00:57:20Z","isPatch":false,"sender":{"key":"parsons.nate@gmail.com","avatar":"https://gravatar.com/avatar/8fbd472c9e74c6f64c305d4ea09575011b36a7844737f47a36f59086d88646fb?d=mp&s=160"},"body":"On Thu, Sep 30, 2010 at 7:45 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:\n> Are you running some anti-virus, or from a Dropbox-folder (or\n> something similar)? If so, these applications tend to open files for a\n> short while and then release the file handle. This can some times\n> cause race conditions with other software, like Git.\n>\n> I haven't looked into this particular code-path for what kind of\n> hazards might be, but this sounds very much like one such case to me.\n>\n\nAny of these things are possible. As much as I'd like to find the root\ncause of this problem, isn't making Git more robust a good thing in\ngeneral? Finding every program that could conflict with Git and\ndisabling/uninstalling it isn't really a good long term solution, I\nthink.\n"},{"id":"152212","messageId":"AANLkTi=ZFb4T+RwT+kkccX0jtyQZxs71eJajSX7KQb+h@mail.gmail.com","threadId":"25094","inReplyTo":"AANLkTik2HtyVGz6xFb_VmCh1gSAA_vwpUXhytHFzgCwa@mail.gmail.com","subject":"Re: git .lock file error","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-10-01T01:59:48Z","receivedAt":"2010-10-01T01:59:48Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Oct 1, 2010 at 2:54 AM, Nate Parsons <parsons.nate@gmail.com> wrote:\n> On Thu, Sep 30, 2010 at 7:45 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:\n>>\n>> Are you running some anti-virus, or from a Dropbox-folder (or\n>> something similar)? If so, these applications tend to open files for a\n>> short while and then release the file handle. This can some times\n>> cause race conditions with other software, like Git.\n>>\n>> I haven't looked into this particular code-path for what kind of\n>> hazards might be, but this sounds very much like one such case to me.\n>\n> Any of these things are possible. As much as I'd like to find the root cause\n> of this problem, isn't making Git more robust a good thing in general?\n> Finding every program that could conflict with Git and\n> disabling/uninstalling it isn't really a good long term solution, I think.\n\nWhile making Git more robust is certainly a worthwhile goal, adding\nretry-loops around any timing-sensitive code without finding out\nexactly what went wrong is just cargo-cult programming.\n\nI don't think I've ever seen such a breakage with open(..., O_CREAT)\nbefore, so I'm sceptical.\n"}]}