On Thu, Dec 05, 2013 at 11:13:42AM +0000, Philip Martin wrote:
> 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.
I think a hotcopy should be a drop-in replica in most respects,
so it can be used easily in case the original repository is lost.
If people want to change access permissions they should do so explicitly.
So copying permissions for directories as well seems like a good idea.
However, it would probably be wise to make any errors encountered while
copying permissions non-fatal, even for files.
A related questions is whether uid/gid should be preserved. I do believe
we we want the copy owned by the uid/gid that performs the hotcopy,
because trying to change the uid/gid of copy destination might interfere
with some backup processes, and could cause surprises with some filesystems
such as NFS where UIDs can vary between systems if no central user
database is used.
Received on 2013-12-05 14:15:20 CET