--On August 24, 2010 1:12:22 PM -0400 Dave McMurtrie <dave64@xxxxxxxxxxxxxx> 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 ---- 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