I've seen a number of corrupted-index problems pop up on our test-dovecot
servers (used by a few people at the office), and I'm wondering why corrupt
indices don't just automatically get deleted ? Something like:
if (!MAIL_INDEX_IS_IN_MEMORY(index)) {
unlink(index->filepath);
}
in src/lib-index/mail-index.c:mail_index_set_error() comes to mind. It seems
to me like it should work, anyway. You can still treat the error like it's
currently treated (as fatal), but at least it won't pop up the next time you
try to perform the same action, or trigger the same corrupted entry another
way.
By the way, I also noticed what is probably an accidental checkin in
src/lib-storage/index/maildir/maildir-storage.c:maildir_get_control_path(),
where it tries to migrate control files from the default location to the
configured location. I think Timo wrote that patch for my colleage Cor, and
then accidentily checked it in with:
----------------------------
revision 1.100
date: 2005-06-09 14:31:43 +0000; author: cras; state: Exp; lines: +22 -4
Replaced ':' and ',' character usages with #defines, so they can
be changed
easily if needed.
The patch is 'broken' anyway; it tries to use rename() to move the old
control files to the new location, but that doesn't quite work between
different filesystems (and that happens to be what we want to do ;). A
better way to handle it would probably be to read in the data from the old
location, and then write it out to the new location, in a normal load/save
procedure. But I think we'll just do the move manually, after all, as
it's
just a few dozen different accounts at the moment. I'm not sure about the
value of the 'implicit' controlfile migration that dovecot currently
does.
--
Thomas Wouters <thomas at xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
On Wed, 2005-07-20 at 17:46 +0200, Thomas Wouters wrote:> I've seen a number of corrupted-index problems pop up on our test-dovecot > servers (used by a few people at the office), and I'm wondering why corrupt > indices don't just automatically get deleted ? Something like: > > if (!MAIL_INDEX_IS_IN_MEMORY(index)) { > unlink(index->filepath); > } > > in src/lib-index/mail-index.c:mail_index_set_error() comes to mind. It seems > to me like it should work, anyway. You can still treat the error like it's > currently treated (as fatal), but at least it won't pop up the next time you > try to perform the same action, or trigger the same corrupted entry another > way.Not all mail_index_set_error() calls are about broken index file. It's just a generic call to set "latest error" value. It's called for example if some file can't be opened. The way it should work is that when actual corruption is noticed, mail_index_mark_corrupted() is called which sets corrupted-flag to the index. At next opening it should then be rebuilt. If some error won't go away automatically I'd like to know error it is. And I guess I should look through all the code paths to make sure that the corrupted-flag is always set when index error is noticed..> By the way, I also noticed what is probably an accidental checkin in > src/lib-storage/index/maildir/maildir-storage.c:maildir_get_control_path(), > where it tries to migrate control files from the default location to the > configured location. I think Timo wrote that patch for my colleage Cor, and > then accidentily checked it in with:Thanks, removed. Probably would have taken a long time for me to see that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050722/704f1d58/attachment-0001.bin>