Possible bug in ctl_mboxlist -u (or perhaps I'm just crazy)

[Michael Bacon]

Hi, all,

In the "bugs that increasingly small number of people are likely to 
encounter" department, I've run into this bug on our upgrade test box on 
the path out of the dark ages, a.k.a. between 1.6 and 2.3.

The 1.6 install uses the flatfile format, and did not include the mbtype 
field.  If viewed with a less -U, it nicely shows all the fields delimited 
with a tab (^I) character:

user.baconm^I112^Ibaconm^Ilrswipcda^I
user.baconm.bedeworks-users^I112^Ibaconm^Ilrswipcda^I
user.baconm.info-cyrus^I112^Ibaconm^Ilrswipcda^I

The upgrade instructions (which are cumulative and ancient, I realize) 
indicate that a ctl_mboxlist -u on a flatfile mailboxes database should be 
enough.  However, this doesn't incorporate the adding of the mbtype field. 
This would be Bug #1 as I see it. (or something that just requires an 
additional step in the upgrade document, which admittedly is not a step 
many people will ever go through again.)

Getting around this is a little tricky, because simply adding an additional 
tab-delimited field with 0 in it right after the mailbox name does not 
work.  Dumping the mailboxes database from a legitimate (I think) skiplist 
file gets me something that looks like this (with less -U, which again is 
turning tabs into ^I):

user.baconm^I0 112 baconm^Ilrswipcda^I
user.baconm.bedeworks-users^I0 112 baconm^Ilrswipcda^I
user.baconm.info-cyrus^I0 112 baconm^Ilrswipcda^I

The partition here is "112".  Now, at first glance, this seems pretty 
wacky, to have the fields delimited with an odd mix of spaces and tabs, but 
hey, whatever works.  I'm pretty sure this isn't just my system being 
buggy, because the code is pretty explicit about what's doing 
(imap/mboxlist.c):

char *mboxlist_makeentry(int mbtype, const char *part, const char *acl)
{
    char *mboxent = (char *) xmalloc(sizeof(char) *
                                     (30 + strlen(acl) + strlen(part)));
    sprintf(mboxent, "%d %s %s", mbtype, part, acl);
    return mboxent;
}

The workaround I think I've developed is to just run the old mailboxes file 
through the following perl snippet before undumping it:

perl -ane 's/\t(\w+)\t/\t0 $1 /; print'

That replaces what was

<mbname>^I<partname>^I<acluid1>^I<aclrights1>^I...

with

<mbname>^I<mbtype> <partname> <acluid1>^I<aclrights1>^I...

(and always uses "0" for the mbtype, which as I understand it is proper for 
an old mailboxes database)

It appears to work on my test system, but this is just strange enough that 
I want to double-check with the kind folks here to make sure this is proper 
and sane before I go and run this on a single 1.6 install with 80k users 
and 800k mailboxes.  So, if this is actually the right thing to be doing, 
please let me know, and if I'm doing something horribly broken, I REALLY 
want to know.

Thanks, y'all,

Michael Bacon
ITS Messaging
UNC Chapel Hill