Stefan Sperling <stsp_at_elego.de> writes:
> On Wed, Dec 04, 2013 at 07:53:40PM +0100, Stefan Sperling wrote:
>> On Wed, Dec 04, 2013 at 06:38:05PM -0000, philip_at_apache.org wrote:
>> > @@ -1314,6 +1314,12 @@ svn_sqlite__hotcopy(const char *src_path
>> > svn_sqlite__db_t *dst_db;
>> > sqlite3_backup *backup;
>> > int rc1, rc2;
>> > + svn_node_kind_t kind;
>> > +
>> > + /* Create empty file first to avoid SQLITE_DEFAULT_FILE_PERMISSIONS. */
>> > + SVN_ERR(svn_io_check_path(dst_path, &kind, scratch_pool));
>> > + if (kind == svn_node_none)
>> > + SVN_ERR(svn_io_file_create_empty(dst_path, scratch_pool));
>> >
>> > SVN_ERR(svn_sqlite__open(&dst_db, dst_path, svn_sqlite__mode_rwcreate,
>> > NULL, 0, NULL, scratch_pool, scratch_pool));
>> >
>>
>> Shouldn't this be using svn_io_copy_perms() instead, so that
>> permissions used by the hotcopy source are replicated?
>
> Done in r1547877.
Is there a rationale for copying the permissions from source to
destination during hotcopy? Hotcopy is a different operation from
normal repository read and write so the user/group/umask used for normal
access could be different from the user/group/umask used to make the
hotcopy. I'd expect hotcopy to respect umask for permissions.
I see that we already copy the permissions for rev and revprop files but
that seems silly to me since we don't copy permissions for directories
like db/ and db/revs/. If we have a repository with group write access:
umask 007
svnadmin create src
svn import -mm repo/format file://`pwd`/src/A/f
then a hotcopy without group write access
umask 022
svnadmin hotcopy src dst
gives group write access to files like db/wc.db and db/txn-current but
will not allow group commits because db/ is group read-only.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-12-05 12:14:34 CET