User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090428 Shredder/3.0b3pre The presence of empty Imap folders in a Gmail account will cause unusually long delays during an off-line folder mail synchronization. Drafts is an example of a commonly empty folder on which Thunderbird 3 beta/Shredder will get stuck on when doing an offline sync, but any empty folder is affected by the issue. Reproducible: Always Steps to Reproduce: 1. Create a gmail account and enable/configure for IMAP 2. Create tags (IMAP folders) that are empty 3. Perform an Offline Download/Sync now operation with Thunderbird 3 beta/Shredder 4. Note the long delay (more than a minute) when an empty folder is encounterd. Actual Results: Follow steps above to reproduce. Expected Results: You will notice a minute or longer delay/timeout as the empty folders are encountered. Empty folders (aka Gmail tags containing no messages) should sync rapidly, as other folders do. Note: This problem only exists in Thunderbird 3 Beta, and recent Shredder versions as well. The problem does not exist in Thunderbird 2.0

(In reply to comment #0) > Drafts is an example of a commonly empty folder on which Thunderbird 3 beta/Shredder will get stuck on when doing an offline sync, > but any empty folder is affected by the issue. What folder of Gmail IMAP do you set as special folder for Tb? > mail.identity.idX.ArchiveFolder > mail.identity.idX.archive_folder > mail.identity.idX.DraftFolder > mail.identity.idX.draft_folder > mail.identity.idX.FccFolder > mail.identity.idX.fcc_folder > mail.identity.idX.StationeryFolder > mail.identity.idX.stationery_folder > mail.server.serverY.spamActionTargetFolder > mail.server.serverY.trash_folder_name When folder is "folder to save draft mail" and if the folder is newly created one(no mail is saved in it yet), Tb seems to fail to check uid validity. Following is log when first access of newly created Drafts folder(==Gmail Label of [Imap]/Drafts) which I took on 2009/2/08 using Tb trunk on MS Win-XP. (mail.identity.idX.draft_folder=imap://.../Drafts, not .../[Gmail]/Drafts) > 6 select "Drafts" > * OK [UIDVALIDITY 602313111] > * 0 EXISTS > * 0 RECENT > * OK [UNSEEN 0] > * OK [UIDNEXT 1] > 6 OK [READ-WRITE] Drafts selected. (Success) > uid validity not ok Above failure disappeared, once a mail was saved in Drafts folder. When Drafts, "uid search message-id <...>" is used for deletion of old draft mail. I guess above "uid validity not ok" is Drafts particular issue(I couldn't see it for newly created Templates folder==Gmail Label of Templates. Anyway, get IMAP log, and check IMAP level flow.

I've had a look at the IMAP log I created, and think the "uid validity not ok" is a red herring. I too saw the error disappear when a message was put in the drafts folder. When the message was removed and the drafts folder was once again empty, the long delay returned, however there was no associated uid validity error. I reiterate that the problem occurs with any empty google imap folder. Create a new folder with Shredder, then perform an off-line sync. The sync will get stuck on the newly created empty folder. Add a message and it goes away. Empty the folder and the delay/hang returns. The "uid validity not ok" error may or may not be present when this occurs. I'll continue to try to correlate the hang with something...

(In reply to comment #2) > When the message was removed and the drafts folder was once again empty, the long delay returned, > however there was no associated uid validity error. "* 0 EXISTS" is cause of problem? As seen in Bug 462880, if "* 0 EXISTS"(select response, IDLE response), mails which are already deleted at server are not removed from thread pane(and MailDB). It indicates that something wrong in Tb around "empty folder".

By the way, if MS Win user, you can get NSPR log with timestamp/sequence number by using DebugView. See bug 402793 comment #6 for NSPR log with DebugView. If you use DebugView, you can do ad-hoc check of IMAP flow while Tb is running, by viewing log data at console window of DebugView.

After reading through Bug 462880 thoroughly, it looks like they're experiencing the same problem, and that it describes the same bug most likely, especially after reviewing https://bugzilla.mozilla.org/show_bug.cgi?id=462880#c10 where they describe the situation where thunderbird will hang for a long time or indefinitely. Thanks for the DebugView info, will follow instructions. Most likely my report is a duplicate of 482880

(In reply to comment #5) > Most likely my report is a duplicate of 482880 Bug 462880 is for "never removed mail even after delete/expunge at server". I believe "never ending file open" part of Bug 462880 should be DUPed to this bug. I'll try to get IMAP log for phenomenon of "never ending file open".

do we need to ping someone at gmail?

Hmm, perhaps. I'll try that.

Brent, are you still seeing this with 3.01 or 3.1b1 pre builds?

Brent, others, does this still reproduce with gmail (or anything else)?

I'll have to check. I am still using Thunderbird, but have avoided the issue by ensuring I have no empty folders. I'll report back what I find.

RESOLVED INCOMPLETE due to lack of response to last question. If you feel this change was made in error, please respond to this bug with your reasons why.

Okay, did a check this morning (installing Thunderbird on a new laptop). Yes, the problem *still exists*. The easiest way to duplicate the issue is: 1. Create an empty folder on your Gmail account that you access via imap. 2. Close Thunderbird. 3. Delete your local imap cache in your profile. 4. Start Thunderbird. 5. Initiate an off-line sync. You will find that the synchronisation process hangs when it gets to the empty imap folder. This is *only* a problem when you're performing a sync of the imap folder structure and you have an empty imap folder on the far end, but no corresponding local cache file. Default folders it will hang on with Gmail include the Spam folder and the Drafts. The work around is to put email messages in these folders (or other empty ones), do a sync to create the local store, then delete the messages. Cheers, Brent

(In reply to comment #14) > Okay, did a check this morning (installing Thunderbird on a new laptop). Yes, > the problem *still exists*. The easiest way to duplicate the issue is: > > 1. Create an empty folder on your Gmail account that you access via imap. > > 2. Close Thunderbird. > > 3. Delete your local imap cache in your profile. > > 4. Start Thunderbird. > > 5. Initiate an off-line sync. > I'm not seeing this with Mozilla/5.0 (Windows NT 5.1; rv:2.0b13pre) Gecko/20110314 Thunderbird/3.3a3 - it finsishes the sync and goes offline.

Brent, do you see this in version 10? Certainly an odd problem

I cant seem to reproduce this. current nightly