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

Re: [Patch] Fix multiple reporting of the same lock in FSFS.

From: Sergey Raevskiy <sergey.raevskiy_at_visualsvn.com>
Date: Mon, 9 Feb 2015 19:24:30 +0300

> This is issue 2507
> http://subversion.tigris.org/issues/show_bug.cgi?id=2507
> Commit does not remove locks, lock removal is a separate step after
> commit. However that doesn't work well when a commit removes a locked
> item, after such a commit the remaining lock is invalid and should not
> apply.

This is another issue. My initial post is about a bug in FSFS that could lead
to unexpected behavior of svn_fs_get_locks() function. What I'm talking about

> However, the walk_digest_files() function wasn't updated to reflect the
> changes from [1] and still iterates the locks in a 'recursive' way. I
> suggest removing recursion from this function, since it can produce
> unexpected results for the caller. I've attached a patch with the test
> and the fix for this issue.

To reproduce this bug in test, I've emulated nested locks by creating a file
('/A'), locking it and then replacing by directory with same name. This looks
like a 'directory lock', and I am trying to say that if this happens in real
life, the FS API would behave incorrectly.

> What happens if you remove /A and resinstate /A as a file, does the lock
> come back?

Received on 2015-02-09 17:24:59 CET

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