The first time you try and archive after launching TB it fails. STR: Launch TB Select a message in 3-pane list Hit "A" or Message-Menu/Archive Nothing happens. No error message generated. Hit A or Message-Menu/Archive again and it works. I've seen this before, but was never sure that I'd hit the key cleanly and it was intermittent, now I've pinned it down to the first Archive after launching TB and its repeatable at least in this version of TB.

An update - this bug occurs one time PER ACCOUNT e.g. Select one account - Hit A - Fails - Hit A - succeeds Switch to other account - Hit A - Fails - Hit A - succeeds

POP3(or Local Folders) folder? Or IMAP folder? Get trace data as first trouble shooting step, please. If POP3(or Local Folders), get NSPR log with timestamp,MSGDB:5,MsgCopyService:5, and get File Monitor Tool log for file access to relevant files(Inbox,Inbox.msf,Archives/yymm,Arcives/yymm.msf etc.). If IMAP, get NSPR log with timestamp,imap:5,MSGDB:5,MsgCopyService:5 In any case, edit log file using Text Editor by yourself, and remove irrelevant data such as mail data lines, remove log for irrelevant server/folder access, remove private data, please.

Ok - logged as suggested, I ran a session to "Get All Mail" immediately prior to doing this, so theres no mail data in the log, but I'm not sure what else is relevant / irrelevant. In this log I .... Ran TB from the script that set debug flags Selected first message in Inbox Hit A - it failed to Archive Hit A again - it archived.

(In reply to Mitra Ardron from comment #3) > Log file as requested Quick log check by "View log file by browser" and repeated "Find archives". 1. "create Archives/2013" fails 10 create "Archives/2013" 10 NO Mailbox doesn't allow inferior mailboxes Correspnding log of "CopyMessages request ..." doesn't look to exist. 2. CopyMessages request -src Inbox -dest Archives 14 uid copy 366621 "Archives" It looks for me; (i) "archive to Archives/yyyy(/mm)" failed because server doesn't permit to create subfolder under Archives, then "first archive request" failed. (ii) Because of (i), archive_granularity is reset to "single folder" internally/temporary, then "second archive request" moved mail to "Archives" folder. Is your "Archive option..." setting of each Identity correct? What is your "Server supports folders ..." setting of Server Settings/Advanced? Do you see your problem in Tb 17? If no, this bug may be regression over Tb 17 by backout of bug 799821, because "list *" is not seen in log although "lsub *" is issued, and \Noinferior etc. is not returned to LSUB command by your server but \Noinferior is returned to LIST command. Do you see your problem with "Show only subscribed folers" Unchecked at Server Settings/Advanced?

Thanks for the analysis Wada, I don't understand what you mean by "Correspnding log of "CopyMessages request ..." doesn't look to exist." I ran the script: export NSPR_LOG_MODULES=timestamp,imap:5,MSGDB:5,MsgCopyService:5 export NSPR_LOG_FILE=/Users/mitra/temp/imap.log echo NSPR_LOG_MODULES=$NSPR_LOG_MODULES to $NSPR_LOG_FILE /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin & Based on what someone else sent me on a previous debug request, with the log_modules you asked for, if it needs to be something different to generate a seperate log (which I think is what you are saying) please be specific and I'll be happy to rerun the test Server supports folders is set, and I see a folder "mail" which has sub-folders (but no messages). I see an "Archives" folder but no "Archives/2013" I don't currently have Tb17 installed and don't really want to go back to it in case it mucks the database up moving backwards, is that likely to happen ? If I uncheck "Show only subscribed folders" then the problem disappears for that account (but remains on the account with "Show only subscribed folders" checked, (they both use the same server). Both these accounts were recently setup as I installed TB on a new laptop, and I didn't change the "advanced settings", i.e. these are default settings.

(In reply to Mitra Ardron from comment #5) > I don't understand what you mean by "Corresponding log of "CopyMessages > request ..." doesn't look to exist." Sorry for my ambiguous comment. I meant "CopyMessages log corresponds to first Archive request" is not seen in your log. - Existent and only log of "CopyMessages request -src Inbox -dest Archives" is for second Archive request by you. - For first Archive request by you, log of "CopyMessages request -src Inbox -dest Archives/2013/..." doesn't look written by Tb, because creation of .Archives/2013 failed. > If I uncheck "Show only subscribed folders" then the problem disappears for that account This is evidence of that this bug is "regression over Tb 17 by backout of bug 799821. There is no need to check with Tb 17. This bug is; Bug 317597 / Bug 534021 has come back, because patch for bug 799821 has been backed out by　bug 799821 comment #27 in order to bypass problem like bug 859269 / bug 897854. If problem like bug 859269 / bug 897854 won't occur with "Show only subscribed folders" Unchecked in your environment, please use your Tb with "Show only subscribed folders" Unchecked in order to bypass problem like Bug 317597 / Bug 534021. Confirming per NSPR log.

Because your IMAP server doesn't support "subfolder under Archives folder, never set other than "a single folder" at "Archive Options..." of each Identity. Unless you set other than "a single folder", this bug won't occur even when Bug 317597 / Bug 534021 happens again. I perhaps have known a reason why you can open so many bugs by testing beta build or daily builds...

I can't leave "Shown only subscribed folders" unchecked as that I can do what you suggest in Comment #7, so I'm fine. But ... we should probably fix this bug. I used standard default settings, so I'm guessing other people will get hit by this bug if they have a similar server. I think this (like many problems) is a symptom of multiple bugs. 1: When the initial archive fails, it does so silently, nothing in Error console, no dialogue box just failure to do what was asked. 2: When it reset the archive_granularity (a good decision I think) it should have then gone ahead and archived the message. 3: When setting up the account maybe it should have checked archive granularity was feasible, especially if there is an "Archives" folder, and no subfolders.

(In reply to Mitra Ardron from comment #8) > I can't leave "Shown only subscribed folders" unchecked as that > I can do what you suggest in Comment #7, so I'm fine. Reason why "leave Shown only subscribed folders unchecked" is needecd and reason why "never use other than 's sinle folder'" is different. "What you choose" is all up to you, though. > 1: When the initial archive fails, it does so silently, nothing in Error console, > no dialogue box just failure to do what was asked. Even when "create folder" or "create subfolder" request from UI failed due to, for eample, "sub foldr of this folder is not supported by server", "used character is not permitted as folder name at server", nothing is notified to user currently. (known bug) I don't think bug for "no error message only when create subfolder failed during archive request only because server doesn't permit subfolder" is helpfull, although such bug can be an incident of a variant of "no error message when folder creation faled". "No error message" or "No appropriate feed back about error" is an attribute of Mozilla family, for example, "No error feed back when filter move failed", "No error feed back when Compact Folder failed", "When Mbox file(not Mbox.msf) is opened by other software, Copy/Move mails to folder named Mbox silently failes, does do nothing", and so on :-) Open separate bug for "appropriate feed back about error while Archive", please. > so I'm guessing other people will get hit by this bug if they have a similar server. Number of IMAP server which produces problem like Bug 317597 / Bug 534021 is not so large. Majority of IMAP servers won't produce problem like Bug 317597 / Bug 534021. Even Dovecot or UW-IMAP, if server is appropriately configured, such problem won't occur. However, "number of Dovecot or UW-IMAP server who produces problem like Bug 317597 / Bug 534021" is not negligible, so patch for bug 799821 was implemented. And, unfortunately "worse Dovecot or UW-IMAP servers who produces problem like bug 859269 / bug 897854" has been found by patch for bug 799821, then patch for bug 799821 has been backed out. Please note that number of "other people" you call is never "many" although it's never negligible. I think majority of "Dovecot or UW-IMAP server who produces problem like Bug 317597 / Bug 534021, bug 859269 / bug 897854" is personal IMAP server with minimum setups, without modifying default settings, or without altering inappropriate sample settings in shipped package.

That could be - the Dovecot I use isn't a personal server (its a company machine) and I have no idea how common it is. Yes I agree, poor error reporting is a meta-problem in TB, (and more generally in much open-source software development). Having a problem - and not being able to fix it because you can't figure out why its broken - is probably a high cause of attrition in TB users (i.e. TB users switching to Apple Mail or whatever).

Mitra, do you still see this in version 31 or newer?

Yes Wayne - it still happens on v32

(In reply to Wayne Mery (:wsmwk) from comment #11) > do you still see this in version 31 or newer? FYI. "backout of patch for bug 799821" had not been done on trunk, so the "patch for bug 799821" was shipped by Tb 31, then problem like bug 859269 / bug 897854 started to occur again although problem of bug 799821 was fixed again, thus "patch for bug 799821" was backed out again in trunk and "patch for bug 799821" was perhaps removed from Tb 32. Watch bug 897854 and relevant bugs, which are already pointed multiple times, please.