Stefan Sperling <[email protected]> writes: > On Wed, Dec 04, 2013 at 07:53:40PM +0100, Stefan Sperling wrote: >> On Wed, Dec 04, 2013 at 06:38:05PM -0000, [email protected] 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*
