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
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
