On Fri, 13 Mar 2009, Dag Nygren wrote:
Ok. Didn't see any warnings on them creating problems. Thought it was more
like fsck. Just rebuilding the metadata from the raw messages.
Good point. Thanks for bringing it up.
Yes, these repair tools are not like fsck. Their task is a single-minded
effort to create usable .mixindex (mixrbld) and .mix######### (mixdfix)
files that (by choosing to run these tools) you have said are unusable for
some reason. In the course of performing that task they will happily
disregard and destroy perfectly valid information.
The equivalent to fsck's "check" functionality is "mailutil check". If
"mailutil check" does not snarl, then there is no reason to run mixrbld or
mixdfix.
An equivalent to the "safe fixing" functionality of fsck is actually built
into the mix code of the c-client library. The mix code is designed to be
self-healing; if it sees a problem that it can fix safely, it will do so
without even asking you.
So, the mixrbld and mixdfix programs are best thought as "unsafe fixing",
to be deployed when, for some reason, the self-healing "safe fixing"
didn't work.
If the mailbox opens, it is not corrupt in any way that mixrbld/mixdfix
can remedy.
So that is a good enough test? Will remember that in the future.
Yes.
Of course the current problem indicates tha opposite as it very well opens,
but still doesn't work as expected...
Whatever anomaly you found is not something that is addressed by mixrbld
or mixdfix. I wish that I knew what that anomaly was.
However, your solution of deleting the .mixstatus file and recreating is
the current way of dealing with .mixstatus issues.
Is ther any documentation on mix?
docs/mixfmt.txt
Just checked the source code and the actual message was from mixrbld and
was the one on row 181, printf ("Data file %s UID ran backwards.....
Isn't that "out of sequence".
The text "out of sequence" does not occur in "Data file...ran backwards",
and thus is a paraphrase. Please don't do that.
OK. But is does mean the same thing :-)
There are numerous things in mix (and IMAP) that are sequenced. There is
also a specific datum that is called a "sequence". Neither of these are
relevant to this warning message.
This warning message merely states that it found a message with a lower
UID value than one it had seen before. Since mix tends to order data
files in ascending order, this is an interesting event worth noting to an
expert repairing the mailbox who wants to understand the nature and scope
of the damage. But this situation in data files is harmless on its own,
and mixrbld is supposed to allow for that.
However, the UW version of mixrbld has a bug in handling this particular
anomaly. That can cause more serious problems later on.
If you got a "Data file...ran backwards" message, it is likely that some
expunge operation did not complete properly. mixrbld will recover from
this.
Shouldn't a rerun of mixrbld be clean in that case?
No. This is a situation in the data files. mixrbld does not change data
files.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
