git .lock file error

Hi everyone,

I'm trying to switch to git, so I apologize in advance for my
ignorance. For this, I'm using cygwin git, version 1.7.1 to talk to a
svn server running 1.4.2.

When I 'git svn clone' or 'git svn clone; git svn fetch', I sometimes
run into the following error.

Couldn't open .git/svn/refs/remotes/0.0.0/.rev_map.b8cad480-e46b-48b4-8317-a683ee46c2bd.lock: Device or resource busy
 at /usr/lib/git-core/git-svn line 5210

And when I 'git svn rebase'

Couldn't open .git/svn/refs/remotes/git-svn/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy
at /usr/lib/git-core/git-svn line 1528

Sometimes the line number is different (578, I think?), but when I
retry the fetch command, it rebuilds the file corresponding to the
lockfile, and then continues a little farther before dying again.

When I watch the directory in question, I see the lock file appear,
and then disappearing a short time after the script gives up.

I don't have a series of steps to reproduce the problem, sometimes it
goes for an hour, and sometimes for just a few minutes/seconds.

I do have TortoiseGit running my machine, but this issue happens even
when TGitCache.exe is not running. If some other instance of git is
accessing the repository, I don't know which or how.

Thanks,
-Nate

Hello again,

I realized I have git-cheetah running as well, so I killed
explorer.exe (the only process using git_shell_ext.exe), and tried
again. That's when I noticed that running 'git svn fetch' spawned two
git processes and a perl process (which later spawned another perl).
Is this something that should be happening?

Thanks,
-Nate

On Mon, Sep 13, 2010 at 11:19 AM, Nate Parsons [off-list ref] wrote:

Hi everyone,

I'm trying to switch to git, so I apologize in advance for my
ignorance. For this, I'm using cygwin git, version 1.7.1 to talk to a
svn server running 1.4.2.

When I 'git svn clone' or 'git svn clone; git svn fetch', I sometimes
run into the following error.

quoted

Couldn't open .git/svn/refs/remotes/0.0.0/.rev_map.b8cad480-e46b-48b4-8317-a683ee46c2bd.lock: Device or resource busy
 at /usr/lib/git-core/git-svn line 5210

And when I 'git svn rebase'

quoted

Couldn't open .git/svn/refs/remotes/git-svn/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy
at /usr/lib/git-core/git-svn line 1528

Sometimes the line number is different (578, I think?), but when I
retry the fetch command, it rebuilds the file corresponding to the
lockfile, and then continues a little farther before dying again.

When I watch the directory in question, I see the lock file appear,
and then disappearing a short time after the script gives up.

I don't have a series of steps to reproduce the problem, sometimes it
goes for an hour, and sometimes for just a few minutes/seconds.

I do have TortoiseGit running my machine, but this issue happens even
when TGitCache.exe is not running. If some other instance of git is
accessing the repository, I don't know which or how.

Thanks,
-Nate

OK, so this is definitely a win32 issue. I believe that the perl
script is simply creating .lock files too fast for Windows to keep up.
Simply trying again fixes the problem for me.

--- a/git-svn.perl
+++ b/git-svn.perl

@@ -3676,8 +3676,10 @@ sub rev_map_set {
 					    "$db => $db_lock ($!)\n";
 	}

-	sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)
-	     or croak "Couldn't open $db_lock: $!\n";
+   my $fh;
+   my $tries=10;
+   for(; !sysopen($fh, $db_lock, O_RDWR | O_CREAT) && $tries>=0; $tries--) { }
+   if($tries <= 0) { croak "Couldn't open $db_lock: $!\n"; }
 	$update_ref eq 'reset' ? _rev_map_reset($fh, $rev, $commit) :
 				 _rev_map_set($fh, $rev, $commit);
 	if ($sync) {

If this is a reasonable solution, I can go figure out how to properly
format a patch to the list.

-Nate

On Sun, Sep 19, 2010 at 10:42 PM, Nate Parsons [off-list ref] wrote:

Hello again,

I realized I have git-cheetah running as well, so I killed
explorer.exe (the only process using git_shell_ext.exe), and tried
again. That's when I noticed that running 'git svn fetch' spawned two
git processes and a perl process (which later spawned another perl).
Is this something that should be happening?

Thanks,
-Nate

On Mon, Sep 13, 2010 at 11:19 AM, Nate Parsons [off-list ref] wrote:

quoted

Hi everyone,

I'm trying to switch to git, so I apologize in advance for my
ignorance. For this, I'm using cygwin git, version 1.7.1 to talk to a
svn server running 1.4.2.

When I 'git svn clone' or 'git svn clone; git svn fetch', I sometimes
run into the following error.

quoted

Couldn't open .git/svn/refs/remotes/0.0.0/.rev_map.b8cad480-e46b-48b4-8317-a683ee46c2bd.lock: Device or resource busy
 at /usr/lib/git-core/git-svn line 5210

And when I 'git svn rebase'

quoted

Couldn't open .git/svn/refs/remotes/git-svn/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy
at /usr/lib/git-core/git-svn line 1528

Sometimes the line number is different (578, I think?), but when I
retry the fetch command, it rebuilds the file corresponding to the
lockfile, and then continues a little farther before dying again.

When I watch the directory in question, I see the lock file appear,
and then disappearing a short time after the script gives up.

I don't have a series of steps to reproduce the problem, sometimes it
goes for an hour, and sometimes for just a few minutes/seconds.

I do have TortoiseGit running my machine, but this issue happens even
when TGitCache.exe is not running. If some other instance of git is
accessing the repository, I don't know which or how.

Thanks,
-Nate

On Thu, Sep 30, 2010 at 18:00, Nate Parsons [off-list ref] wrote:

OK, so this is definitely a win32 issue. I believe that the perl
script is simply creating .lock files too fast for Windows to keep up.
Simply trying again fixes the problem for me.

Sounds like something that might do with a non-hacky solution, but I
don't know what that would be.

-       sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)
-            or croak "Couldn't open $db_lock: $!\n";
+   my $fh;
+   my $tries=10;
+   for(; !sysopen($fh, $db_lock, O_RDWR | O_CREAT) && $tries>=0; $tries--) { }
+   if($tries <= 0) { croak "Couldn't open $db_lock: $!\n"; }
       $update_ref eq 'reset' ? _rev_map_reset($fh, $rev, $commit) :
                                _rev_map_set($fh, $rev, $commit);
       if ($sync) {

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;'