On Thu, Nov 25, 2010 at 02:12:46AM -0500, Giles Malet wrote: > 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.
Now the bug in mailbox renames is "interesting". I have a suspicion that it's actually this: http://git.cyrusimap.org/cyrus-imapd/commit/?id=1988d5fa96f2df88150ece97838469faf092cba1 Since you're running murder. Fixed in git, but that's not much help to you... We'd better get on to releasing a 2.4.5! > 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); Oh - that's bad. It's bogus for "isremote" too. Ouch. > In our case, that `if' statement is false (dbonly=1), so newmailbox > is not initialised: Yeah, of course it isn't, and unsurprisingly it crashes! Now that's definitely a bug, and a blocker at that. It SHOULD be calling the mailbox_open_advanced codepath, but without a mailboxes.db entry. Hmm. Ok. http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3351 Unfortunately I don't have a one-line fix for you :( I'll have to think about it, and it's about 10:15pm at night and my birthday tomorrow, so I don't know that I'll be able to fix it immediately! But it will definitely get fixed within this week. I do recommend the patch above to fix the rename issue. I'll talk to Jeroen about planning a 2.4.5 for next week. Bron.
