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

Wesley Craig wes at umich.edu
Thu Jan 15 19:53:06 EST 2009

Regarding the odd mix of tab vs spaces:


According to the change log, this was to be compatible with  
cyr_dbtool.  However, on undump, it appears to accept space or tab.

Regarding the additional flag:


The flag is optional on undump, defaulting to 0 (a local, active  
mailbox).  If either of these backwards compatible features is  
tripping you up, then please file a bugzilla report: it should work.   
I do notice that since your partition names start with a digit,  
probably the backward compatibility code is insufficient...

Hope this helps on your adventures navigating from 1.6 to 2.3!


On 15 Jan 2009, at 18:04, Michael Bacon wrote:
> 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  
> 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
> !DSPAM:496fc1d3290211336712104!

More information about the Info-cyrus mailing list