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:
https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/
ctl_mboxlist.c.diff?r1=1.56;r2=1.57
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:
https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/
ctl_mboxlist.c.diff?r1=1.43.2.6;r2=1.43.2.7
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!
:wes
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
> 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
>
> !DSPAM:496fc1d3290211336712104!
>
>
>
More information about the Info-cyrus
mailing list