Hello folks,
We seem to have a bug in mailbox renames in 2.4.4 that is leaving
mailboxes in funny states. I think the new mailbox is not added to the
mboxlist yet the old is removed, and the folder is untouched on disk....
but I got sidetracked on that trying to do reconstruct -rf to get the
lost folders back - and that crashes reconstruct! Doing -rfx instead
avoids the crash, but has the side-effect of course of clobbering the
mailbox flags.
The problem is in mboxlist_createmailbox_full() in mboxlist.c:
struct mailbox *newmailbox = NULL;
[...]
if (!dbonly && !isremote) {
/* Filesystem Operations */
r = mailbox_create(name, newpartition, acl, uniqueid,
options, uidvalidity, &newmailbox);
}
[...]
/* all is well - activate the mailbox */
mboxent = mboxlist_makeentry(newmailbox->mbtype, newmailbox->part,
newmailbox->acl);
In our case, that `if' statement is false (dbonly=1), so newmailbox is
not initialised:
Program received signal SIGSEGV, Segmentation fault.
0x08055766 in mboxlist_createmailbox_full (
name=0x81b5128 "user.testmail.watpd", mbtype=0, partition=0x0,
isadmin=1,
userid=0x809df95 "cyrus", auth_state=0x0, options=1,
uidvalidity=1290667775, copyacl=0x0, uniqueid=0x0, localonly=0,
forceuser=0, dbonly=1) at mboxlist.c:617
617 mboxent = mboxlist_makeentry(newmailbox->mbtype,
newmailbox->part,
(gdb) print newmailbox
$1 = (struct mailbox *) 0x0
(gdb)
This is on a cyrus murder, if that matters.... If I can get reconstruct
to work I can make some unhappy users a bit happier, then work on
finding what's causing the damage in renames.
BTW, I turned off delayed_delete and delayed_expunge as I heard there
were bugs there (probably because of the rename problem), but no luck.
Any tips on fixing this greatly appreciated :-)
Thanks,
gdm
