[SVN-3596] 'hotcopy' of fsfs repos may corrupt target rep-cache.db or revprops.db

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: trunk
• Fix Version/s: 1.7.0
• Component/s: libsvn_fs_fs
• Assignee: Unassigned
• Reporter: Daniel Shahaf
• Created: 27/Feb/10 16:03
• Updated: 02/Mar/21 15:41
• Resolved: 18/May/11 10:18

Description

(description copied from the attached thread)

fs_fs.c:svn_fs_fs__hotcopy() uses this code to copy revprops.db:
1597   /* Copy the packed revprop db. */
1598   if (format >= SVN_FS_FS__MIN_PACKED_REVPROP_FORMAT)
1599     {
1600       SVN_ERR(svn_io_dir_file_copy(src_subdir, dst_subdir, PATH_REVPROPS_DB,
1601                                    pool));
1602     }

This post <http://thread.gmane.org/gmane.comp.db.sqlite.general/48391/focus=48423> 
on the sqlite-users mailing list implies that an exclusive lock must be
used for copying an sqlite db, and that plain copying might result in
a corrupt database.

As far as I can see, 'hotcopy' doesn't take the steps recommended
in that (sub)thread to avoid corruption.

Could someone more familiar with sqlite comment on this?  Could
'hotcopy', as now written, potentially corrupt the revprops db
(of the hotcopy target)?

http://article.gmane.org/gmane.comp.version-control.subversion.devel/118341

Issue Links

• blocks: SVN-3885 FSFS corruption issues