Thunderbird large IMAP folder problems

[adobrin]

It appears that there is some sort of interoperability issue between Thunderbird and the IMAP server. When downloading rather large IMAP folders, thunderbird takes a very long time to display list contents. I get "opening folder, sending credentials" then it switches to "Compacting Folder" and hangs for several hours before displaying the contents.

This is 1.07 under debian; I *do not* have this issue with evolution on the same machine.

FYI, we're probably talking somewhere around 5-10,000 messages in these folders.

[adobrin]

I'm reading about what "Compacting Folder" does, and thinking this is probably related to my previous issue, which resulting in me mass deleting all imported messages and reimporting them.

still, taking an awful long time.

[KevinH]

So does this happen *everytime*. I noticed this the first time I sync'd my mail box with Thunderbird (I've got aout 9000 messages in my INBOX). After that it seems quick to open folders.

[adobrin]

I think there's alot more involved here than just the intial download of mail headers. I had scripthacked imapsync to delete and insert the contents of hte mailbox b/c of the initial internal-dates problem I was having, and I didn't know what I was doing. I'm going to resync now and see if it fixes the problems. I think i've left thousands of orphaned mails in the server. Shrug.

Right now, Imapsync is giving me append errors when i try to resynchronize, and some of the folders are not containing all of the mail that was originally in them. Strange behavior.

[adobrin]

Is there a preferred method of deleting mailbox contents?

[adobrin]

and um, is it normal that /opt/zimbra/bin/zmpurgemessages gives me a perl INC error?

[zimbra@dork bin]$ ./zmpurgemessages
Can't locate zimbralog.pm in @INC (@INC contains: /opt/zimbra/zimbramon/lib/i386-linux-thread-multi /opt/zimbra/zimbramon/lib /opt/zimbra/zimbramon/lib/zimbrapm/SOAP /opt/zimbra/zimbramon/lib/zimbrapm /opt/zimbra/zimbramon/lib/i386-linux-thread-multi/ /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at ./zmpurgemessages line 35.
BEGIN failed--compilation aborted at ./zmpurgemessages line 35.

and

use zimbralog; #(at line 35)

[adobrin]

ok.

i've reinstalled everything from scratch, reimported email from cyrus, and reprovisioned the accounts. everything is working much better now.

i don't think i should have been able to f-up the message store so badly, though, using only imapsync--which utilizes Mail::IMAPClient basically, i used imapsync to mass delete all of the messages in the store, using

$to->deletemessage($t_msg); from line 948 to line 936;
which should have deleted everything where the internal-date's were not synced.
then i reran imapsync to reimport the messages with --syncinternaldates.

this appeared to work. though, only for some folders--which is weird. (the ones where it did not appear to work, the internaldates did not change, and still only one copy of the email).


so basically, the moral of the story is, remember to --syncinternaldates the first time.

[gfdos.sys]

I had best luck using

imapsync --nosyncacls --syncinternaldates --user1 [username] --password1 [password] --user2 [username] --password2 [password]

Although the shell batching listed in the README file with imapsync...tweeked just a little produced great results:

created file.csv with content like:

username1;password1
username2;password2
username3;password3

for all my users...
then put this script at the command line

{ while IFS=';' read u1 p1; do
imapsync --nosyncacls --syncinternaldates --user1 "$u1" --password1 "$p1" --user2 "$u1" --password2 "$p1"
done ; } < file.csv