Oh, I'm sorry. I forgot about that commit message change you requested.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1042 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1042#event-3073151509___
Rpm-maint mailing list
Right, I'm by no means opposed to this, and integrating with rpmdb is certainly
the way to go, rather than strange external tools. Was just curious about the
concrete difference.
Can you update the commit message to elaborate a bit on how it works and
possible side-effects, at least that part
@mlschroe pushed 1 commit.
dd4bb9f38fdf1d147a09ca0cdbf38ed75e409b17 Add a --salvagedb option to the rpmdb
tool
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
No, there's a (very) small chance that it picks up entries that have been
deleted. It's like the .recover command of the sqlite cli:
Like the ".dump" command, ".recover" attempts to convert the entire contents of
a database file to text. The difference is that instead of reading data using
the
I'm not all that familiar with ndb internals: how is this different to the
regular --rebuilddb just skipping any headers it finds invalid? Or to turn the
question around: is there a reason why this could/should not be used on all
--rebuilddb operations (on ndb)?
--
You are receiving this
This can be used to recover as much data as possibly from a terminally broken
database. It is currently only supported for the ndb database.
This method is currently hidden from the API by using a macro to select salvage
mode. If it should be more exposed, we can add a rpmtsSalvageDB() method.
