Monotone always works hard to verify the data it creates and accesses.
For instance, if you have hard drive problems that corrupt data in
monotone's database, and you attempt to retrieve this data, then
monotone will notice the problem and stop, instead of silently giving
you garbage data.
However, it's also nice to notice such problems early, and in rarely
used parts of history, while you still have backups. That's what this
command is for. It systematically checks the database dbfile to
ensure that it is complete and consistent. The following problems are
detected:
- missing files
that are referenced by their sha1 hash from some manifest but do not
exist in the database. This is a serious problem; it means that your
history is not fully reconstructible. You can fix it by finding the
file with the given hash, and loading it into your database with
fload.
- unreferenced files
that exist in the database but are not referenced by their sha1
hash from any existing manifest. In itself, this only indicates some
wasted space, and is not a problem; it's possible it could arise under
normal use (for instance, in some strange corner cases following an
incomplete netsync). It could also arise, though, as a symptom of some
other more serious problem.
- missing manifests
that are referenced by their sha1 hash from some revision but do
not exist in the database. This is a serious problem; it means that
your history is not fully reconstructible. You can fix it by finding a
database containing the manifest, and using mdata on that
database to create a manifest data packet, which can be loaded into your
database with read.
- unreferenced manifests
that exist in the database but are not referenced by their sha1
hash from any existing revision. In itself, this only indicates some
wasted space, and is not a problem; it's possible it could arise under
normal use (for instance, if you have run db kill_rev_locally,
or in some strange-but-harmless corner cases following an incomplete
netsync). It could also arise, though, as a symptom of some other more
serious problem.
- incomplete manifests
that exist in the database but contain references to files that do not
exist in the database. For diagnosis and solution, see “missing
files” above.
- missing revisions
that are referenced by their sha1 hash from some other revision or
revision cert but do not exist in the database. This may be a serious
problem; it may indicate that your history is not fully reconstructible
(if the reference is from another revision) or that someone is creating
bogus certs (if the reference is from a cert). You can fix it by
finding a database containing the revision, and using rdata on
that database to create a revision data packet, which can be loaded into
your database with read.
- incomplete revisions
that exist in the database but contain references to missing manifests,
incomplete manifests or missing revisions. This always occurs with some
more detailed error; see above.
- revisions with mismatched parents
that disagree with the cached revision ancestry on their parent
revisions. This may cause problems in using the database, and suggests
the presence of a bug in monotone's caching system, but does not involve
data loss.
- revisions with mismatched children
that disagree with the cached revision ancestry on their child
revisions. This may cause problems in using the database, and suggests
the presence of a bug in monotone's caching system, but does not involve
data loss.
- revisions with bad history
that exist in the database but fail monotone's normal sanity checks for
consistent and correct history. This is a serious problem; it indicates
that your history record is somehow malformed. This should not be
possible, since monotone carefully checks every revision before storing
it into the database, but if it does, then please request assistance on
the monotone mailing list. Fixing this generally means you may lose
some history — for instance, renames may be degraded into delete/add
pairs — but the actual contents of every revision will still be
reproducible.
- revisions with missing certs
that exist in the database lacking at least one author, branch,
changelog or date cert. All revisions are expected to have at least one
of each of these certs. In itself, this is not necessarily a problem,
but it is peculiar, and some operations such as netsync may behave
strangely.
- revisions with mismatched certs
that exist in the database with differing numbers of author, changelog
and date certs. These certs are expected to appear together, as each
revision committed should have an author, changelog and date associated
with it. In itself, this is not a problem, but it is peculiar. All
operations should behave normally.
- missing keys
that have been used to sign certs but do not exist in the database. In
itself, this is not a problem, except that monotone will ignore any
certs signed by the missing key. You can fix it by finding a database
containing the key in question, and using pubkey on that
database to create a public key packet, which can be loaded into your
database with read.
- certs with bad signatures
that exist in the database with signatures that are invalid. In itself,
this is not a problem, except that monotone will ignore any such certs.
You may also wish to find out who is creating certs with bad
signatures; it may indicate some kind of security attack.
- certs with unchecked signatures
that exist in the database but cannot have their signatures checked
because the signing key is missing. In itself, this is not a problem,
except that monotone will ignore any certs signed by the missing key.
You can fix it by finding a database containing the key in question, and
using pubkey on that database to create a public key packet,
which can be loaded into your database with read.
This command also verifies that the sha1 hash of every file, manifest,
and revision is correct.