[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Suspected issue with "remove-zombie-locks.py"?

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 6 Mar 2017 16:30:26 +0000

Stefan Sperling wrote on Mon, Mar 06, 2017 at 17:22:14 +0100:
> On Mon, Mar 06, 2017 at 04:06:44PM +0000, Daniel Shahaf wrote:
> > I can reproduce this using the FS API only (without the contrib/ script):
>
> Hmm, looks like the contrib script is using the API wrong.
> Check out what 'svnadmin unlock' does:
> [[[
> /* Open the repos/FS, and associate an access context containing
> USERNAME. */
> SVN_ERR(open_repos(&repos, opt_state->repository_path, opt_state, pool));
> fs = svn_repos_fs(repos);
> SVN_ERR(svn_fs_create_access(&access, username, pool));
> SVN_ERR(svn_fs_set_access(fs, access));
>
> SVN_ERR(svn_utf_cstring_to_utf8(&lock_path_utf8, lock_path, pool));
> if (opt_state->bypass_hooks)
> SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
> FALSE, pool));
> else
> SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
> FALSE, pool));
> ]]]
>
> The script should probably be doing something like this, too.

I don't think so. The documentation of svn_fs_unlock() points to
the documentation of svn_fs_unlock_many(), which states:

 * If @a fs has no username associated with it, yield an
 * #SVN_ERR_FS_NO_USER (E160034) unless @a break_lock is specified.

The reproductions pass break_lock=True, so shouldn't get that error.

Cheers,

Daniel

> Doug, I believe filing a bug is entirely appropriate here. Thanks!
Received on 2017-03-06 17:37:07 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.