Stuck mailboxes.db entries with mbtype=2

[Michael Bacon]

--On August 24, 2010 1:12:22 PM -0400 Dave McMurtrie 
<dave64 at andrew.cmu.edu> wrote:

> On 08/24/2010 11:21 AM, Michael Bacon wrote:
>> Hi, all,
>>
>> Do to an error I made in migrating a file system during some system work,
>> we ended up with our configdirectory with permissions that the cyrus user
>> couldn't write to on a few of our back-end servers.  Amazingly, we were
>> about 90% functional during this time, but several mailboxes that got
>> created during that time ended up with some decidedly messed-up
>> characteristics.
>>
>> Most we've been able to fix with reconstruct, but we're stuck with a few
>> hundred mailboxes where the backend created the mailbox on disk,
>> registered it with the MUPDATE server, but left it in "reserved" state
>> in the local (backend) mailboxes.db with mbtype=2.  This means that it
>> shows up in a LIST or LSUB with the \NoSelect flag, and the users can't
>> do anything with it, including delete it.
>>
>> I know I could do some pretty heavy-handed stuff to clear this condition,
>> like dumping the mailboxes database, modifying it by hand, and then
>> undumping it, but I'm looking for a less invasive procedure to clear this
>> condition.  Is there any relatively straightforward way to get the
>> mailboxes.db to notice that there's an actual, good copy on disk, and
>> re-set the mbtype to 0?
>
> If the mailbox structure has been successfully created already and your
> problem really is just the mbtype listed in the mailboxes database, I
> think you should be able to rectify this by sending an ACTIVATE command
> to the mupdate server for the affected mailboxes.
>
> http://tools.ietf.org/html/draft-siemborski-mupdate-04#section-9.1
>
> For example, using mupdatetest:
>
> $ mupdatetest -m GSSAPI your.mupdate.server.com.
> S: * AUTH "GSSAPI"
> S: * COMPRESS "DEFLATE"
> S: * PARTIAL-UPDATE
> S: * OK MUPDATE "your.mupdate.server.com" "Cyrus Murder" "v2.3.16"
> "(master)"
> C: A01 AUTHENTICATE "GSSAPI" {752+}
> ...snipped...
> S: A01 OK "Authenticated"
> Authenticated.
> 1 ACTIVATE "user.testuser" "your.cyrus.backend.com!u1" "testuser
> lrswipcda" 1 OK "done"
> 2 logout
> 2 OK "bye-bye"

Definitely something I hadn't thought of, but in this case, the faulty 
mbtype appears to be in the mailboxes.db on the backend server, not the 
mupdate server.  I don't think an MUPDATE command would change that, would 
it?

Michael Bacon
ITS Messaging
UNC Chapel Hill