Not so much if, but when redland corrupts its db4 files here is a series of commands that you might want to shove into a script. Though you really want to setup daily db_dumps that are archived if you use redland for data you care about.
I have attempted and posted a patch and nagged to get this fixed mainline. But I'm not holding my breath that it will be fixed any time soon. I might have to dump redland, fork it proper, or some other nasty solution to stop libferris users complaining about apps "crashing" which is directly due to redland getting its db4s stuffed.
You get the pleasure of running this on all your redland db4 files to try to recover (at least you can run client apps again without a segv in the redland code).
$ db_dump -r myrdf-so2p.db > myrdf-so2p.dump
db_dump: myrdf-so2p.db: DB_VERIFY_BAD: Database verification failed
$ rm -f myrdf-so2p.db
$ db_load -f myrdf-so2p.dump myrdf-so2p.db
$ rm -f myrdf-so2p.dump
The public bug is here
http://bugs.librdf.org/mantis/view.php?id=104
2 comments:
I suggested in the bug report how to rewrite your patch to make it acceptable. The rest is up to you
Dave
I guess I should have blogged this after a longer 'cooling off' period. It was a little too close to when I discovered that a moderate sized RDF database was giving segv and the infamous backtrace through redland calls that I recognized as the sign of database corruption.
I was always hopeful that somebody with corporate backing would be bitten badly enough to cleanup my patch for me and get it upstream...
I'm not sure if/when I'll actually have the time to clean things up for upstream.
One motivation for the blog post is so I know where to easily get the info for fixing a redland store when traveling.
Post a Comment