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

Re: svn: database disk image is malformed

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 18 Dec 2010 20:41:43 +0200

CC += dev@

Stefan Sperling wrote on Thu, Dec 16, 2010 at 18:49:22 +0100:
> On Thu, Dec 16, 2010 at 05:03:00PM +0100, Rainer Dorsch wrote:
> > I try to commit the change
> >
> > $ svn commit -m "minor change"
> > Sending README
> > Transmitting file data .svn: Commit failed (details follow):
> > svn: database disk image is malformed
> > svn: database disk image is malformed
> > $
> >
> > And get an error back.
...
> > I found several posts discussing the
> >
> > svn: database disk image is malformed
> >
> > issue. The best solution is saw is to dump the repository and create a new one
> > from the dump.
> >
> > Is there an easier way to fix the problem in a robust manner? Does maybe even
> > svn provide some fix scripts?
>
> This error message is coming from sqlite, not from Subversion.
> You probably have a broken sqlite database in the repository.
>
> The only place I can think of where sqlite is used in FSFS is
> the rep-cache.db file.

[ For future archeologists, format-5 fsfs repositories (which will
created by Subversion 1.7) will also use sqlite for the revprops.db
file. ]

> Have you got rep-sharing enabled on the repository?
> See the file repos/db/fsfs.conf.
>
> You can safely disable rep-sharing. Maybe this will get rid of the error.
> If it does, try to recover the rep-sharing.db using sqlite (though I
> don't know how you could do that). If you cannot recover rep-cache.db,
> move it out of the way and Subversion will create a new rep-cache.db
> sqlite database. But it will be empty.
>
> Representation sharing is not required for a commit to succeed.
> This would explain why you see a successful commit in spite of the error.
>

How about the second hunk of this patch then?

I haven't compiled it, and it abuses error codes (to use the
specific error code that clients recognize), but is the idea sound?

[[[
Index: subversion/libsvn_fs_fs/fs_fs.c
===================================================================
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1044834)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -5426,9 +5426,20 @@ rep_write_contents_close(void *baton)
   /* Check and see if we already have a representation somewhere that's
      identical to the one we just wrote out. */
   if (ffd->rep_sharing_allowed)
- /* ### TODO: ignore errors opening the DB (issue #3506) * */
- SVN_ERR(svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
- b->parent_pool));
+ {
+ svn_error_t *err;
+ err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
+ b->parent_pool);
+ if (err)
+ {
+ /* Something's wrong with the rep-sharing index. We can continue
+ without rep-sharing, but warn.
+ */
+ (fs->warning)(fs->warning_baton, err);
+ svn_error_clear(err);
+ old_rep = NULL;
+ }
+ }
   else
     old_rep = NULL;
 
@@ -6377,12 +6388,22 @@ svn_fs_fs__commit(svn_revnum_t *new_rev_p,
  SVN_ERR(svn_fs_fs__with_write_lock(fs, commit_body, &cb, pool));
 
   if (ffd->rep_sharing_allowed)
     {
- /* ### TODO: ignore errors opening the DB (issue #3506) * */
- SVN_ERR(svn_fs_fs__open_rep_cache(fs, pool));
- SVN_ERR(svn_sqlite__with_transaction(ffd->rep_cache_db,
+ svn_error_t *err = SVN_NO_ERROR;
+
+ if (! err)
+ err = svn_fs_fs__open_rep_cache(fs, pool);
+
+ if (! err)
+ err = svn_sqlite__with_transaction(ffd->rep_cache_db,
                                            commit_sqlite_txn_callback,
- &cb, pool));
+ &cb, pool);
+
+ if (err)
+ /* The opposite of svn_error_quick_wrap(): same error message,
+ different error code. */
+ return svn_error_create(SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED, err,
+ /* TODO: svn_error_best_message() */ (err)->message);
     }
 
   return SVN_NO_ERROR;
]]]

> Stefan
Received on 2010-12-18 19:44:45 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.