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

FSFS7: 'svnadmin hotcopy' requires write access to the source

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Tue, 16 Jun 2015 21:12:07 +0300

FSFS7 introduced a new on-disk lockfile, db/pack-lock, that allows packing
a repository without completely blocking the commits. We also extended the
svn_fs_fs__hotcopy() logic to take this lock for the source repository, see
r1589284 and the related discussion [1, 2].

I think that this behavior — taking a lock in the filesystem of the source
repository — is a regression, because now 'svnadmin hotcopy' requires write
access to the source repository. One example of how this prerequisite could
break existing installations would be a system where an account performing
the backup only has read access to the source (that sounds logical to me).
Another example would be using 'svnadmin hotcopy' to import an existing
repository from something like a read-only SMB share, and an attempt to do
so would trigger an error for FSFS7 repositories.

Here is a quick reproduction script:

$ svnadmin create source
$ svnadmin create source-old --compatible-version=1.8
$ chmod -w -R source
$ chmod -w -R source-old
$ svnadmin hotcopy source target
svnadmin: E000013: Can't open file 'source/db/pack-lock': Permission denied
$ svnadmin hotcopy source-old target-old
* Copied revision 0.

Please note that the existence of db/pack-lock in the source is orthogonal to
this reproduction script. Calling 'echo "" > source/db/pack-lock' after the
first step would still trigger the same error for the FSFS7 repository.

Perhaps we should add a corresponding regression test and revert r1589284?

[1] https://svn.apache.org/r1589284
[2] http://svn.haxx.se/dev/archive-2014-07/0124.shtml

Regards,
Evgeny Kotkov
Received on 2015-06-16 20:12:58 CEST

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