Best way to reconstruct metadata for a user's folder?

[Skip Morse]

On Mon, Nov 8, 2010 at 9:55 AM, Skip Morse <skipmorse at gmail.com> wrote:
> On Mon, Nov 8, 2010 at 2:10 AM, Gunnar Wrobel <wrobel at kolabsys.com> wrote:
>> Zitat von Skip Morse <skipmorse at gmail.com>:
>>
>>> It appears that I may have something wrong with a user's folder.
>>>
>>> As far as I can tell it's just the user's "Outlook Inbox" that is
>>> effected.  I'm not really sure what's going wrong, only that when I'm
>>> in cyradm and issue: info "user/problemuser/Inbox at domain.com" cyradm
>>> will hang without displaying any info.
>>>
>>> I've tried sharing that user's folder with my user to see if the
>>> change might some how force a recreation of the metadata (didn't
>>> work), it also would not allow me to 'download' via the toltec
>>> connector any of the mails in that folder.  Horde will also timeout if
>>> I click on that folder to view it's contents.
>>>
>>> What's the best way to correct this?
>>>
>>> There are a bunch of folders beneath the "Inbox" folder (they have not
>>> problems with 'info'), if I need to delete the "Inbox" folder, then
>>> recreate it (or let the Toltec connector recreate it), I guess I could
>>> just take all those folders and move them to a new parent folder
>>> first.  I'm thinking Horde might be quickest/best for this. Then copy
>>> all the mails from 'Inbox' to somewhere, then just delete that folder?
>>>
>>> I'm also wondering if a name change might work?
>>>
>>> OR
>>>
>>> If I could just set the metadata manually that would probably be the
>>> easiest, but I've tried modifying an entry from another mailbox (using
>>> out put from "kolab-mailboxinfo.pl -c") and it must not have worked
>>> because it still doesn't display:
>>>
>>> mboxcfg "user/problemuser/Inbox at domain.com"
>>> /vendor/kolab/folder-type mail.inbox
>>>
>>> Maybe there's a step I'm missing, I haven't really been able to come
>>> up with a good google search term.  Maybe there's something in the
>>> metadata that I need to remove that's causing this issue?
>>>
>>> So far this seems to be the only user and folder effected on the
>>> system... but after fixing this I'll run the script again and see if
>>> it fails anywhere else...
>>
>> This sounds like you should use the "/kolab/bin/cyrreconstruct" tool
>> on the folder. It is a somewhat cryptic command but I believe our wiki
>> lists how to use it. It should fix the cyrus databases for the folder.
>>
>> Of course before fiddling around with any of this you should ensure
>> you have a decent backup of the data.
>>
>> Cheers,
>>
>> Gunnar
>>
>
> Thanks, I really appreciate the response.
>
> I was thinking that might do the trick, I was sure if it would really
> recreate the folder or not.  It's definitely worth a shot and sounds
> like that would be the easiest way to do it.  I'm in the process of
> getting a test server going (this is in VM anyway, so it makes it a
> little easier), I'll try it there first and report back.
>
> -Skip
>

Okay, I've got a test system up and running, and I've been trying some
different veriations of the cyrreconstruct as suggested:
http://wiki.kolab.org/Backups_for_kolab2#IMAP_store_recovery_.28cyrus.29

It's not working, but I'm pretty sure that I'm not running it correctly.

per the above link, this should work:
#su - kolab-r -c "/kolab/bin/cyrreconstruct -rf
user/problemuser/Inbox*@domain.com"

** I actually think the option I would want here would be "-x", and
I've tried that too:
#su - kolab-r -c "/kolab/bin/cyrreconstruct -x
user/problemuser/Inbox at domain.com"

I've even tried to su to kolab-r and then just run the commands that
way, I continue to get this error:
fatal error: can't fstat cache file

If i leave off the domain portion, it seems to complete, but I'm not
sure it has done anything.  If I were to use the "-rfx" option I would
expect to see all of the mails looking as new.  I even tried to run it
using the "-C" option and specifying /kolab/etc/imapd/imapd.conf,
didn't seem to matter...

Thoughts anyone?

** Oh, and to verify, I'm checking horde and also checking cyradm's
'info' which hangs on this folder... presumably because the
annotations or metadata are messed up on this folder...

Thanks in advance...
-Skip