Greg Stein <gstein@lyra.org> writes:
> On Wed, Jan 15, 2003 at 02:25:28PM -0600, sussman@tigris.org wrote:
> > Author: sussman
> > Date: 2003-01-15 14:25:18 -0600 (Wed, 15 Jan 2003)
> > New Revision: 4396
> >
> > Modified:
> > trunk/subversion/libsvn_repos/repos.c
> > trunk/subversion/svnadmin/main.c
> > Log:
> >
> > Fix two small annoyances with 'svnadmin recover'.
> >
> > * repos.c (svn_repos_recover): if the db lockfile is already
> > unlocked, don't freak out. move on to the recovery step.
> >...
> > +++ trunk/subversion/libsvn_repos/repos.c Wed Jan 15 14:25:25 2003
> > @@ -977,7 +977,7 @@
> > "svn_repos_recover: error opening db lockfile");
> >
> > apr_err = apr_file_unlock (lockfile_handle);
> > - if (apr_err)
> > + if (apr_err && ! APR_STATUS_IS_EACCES(apr_err))
> > return svn_error_createf
> > (apr_err, NULL,
> > "svn_repos_recover: failed to delete all locks on repository `%s'.",
>
>
> Of course it will freak out. You can't necessarily unlock the lock file from
> a different process. I just looked at this code, and I really don't
> understand what the heck it is attempting.
Heh, I wrote this whole function a few months back, and I don't
either.
I think it's because svn_repos_open() calls get_repos(), which
1. opens the bdb environment, 2. creates a lockfile, 3. uses
apr_file_lock() to exclusively lock it, and 4. attaches a pool cleanup
handler which runs apr_file_unlock(). I presume this prevents two
different processes from opening the repository at the same time?
When I wrote svn_repos_recover(), I didn't really understand what was
going on with all this lock/unlock stuff. I just assumed that before
running the db recovery function, we needed to get exclusive control
of the repository first. Hence the call to apr_file_unlock(). But
maybe this is a bogus strategy?
Brandon Ehle was noticing that on Linux, my apr_file_unlock() call
worked fine, but on win32, it was returning an error: "file already
unlocked". And then of course it would quit without running recovery.
So what's going on here?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 16 16:55:56 2003