Every time I select the Drafts folder for one of my IMAP accounts, Thunderbird opens an alert dialog with the message "The current command did not succeed. The mail server responded: UID COPY failed." Nevertheless, it shows me most of the messages in that folder, although it doesn't show the one I saved today. I see this with the latest Linux nightly, but I can't reproduce with the latest Mac nightly. There, Thunderbird opens the folder without complaint and does show me the draft message I saved today.
I can also access the Drafts folder using Mail.app, and I can access other folders in that IMAP account and the Drafts folder in another IMAP account on a different server. It's only the combination of that particular folder and Thunderbird running on my Linux VM that exhibits the problem.
(A) Mail of the UID exists on IMAP server, but server returned NO to UID COPY? (B) Or mail of the UID is already expunged by someone and NO to UID COPY? If (B), See Bug 466637(due to Bug 465800. See Bug 465800 Comment #3). See also Bug 449088. Bug 465800 is already WORKSFORME with Tb trunk. See Bug 466637 Comment #6, Bug 465800 Comment #6 & #7. > I see this with the latest Linux nightly See Bug 449088 Comment #34. When (B), rebuild Index seems to be required once garbage was generated in MailDB, even after Bug 465800 is resolved. It seems to be problem (A). If problem can still be produced on Linux, get IMAP log and check IMAP level flow first.
Note: that draft I saved yesterday eventually showed up, even though I continued to see the alert when selecting the folder. Per comment #2, I have rebuilt the index for that folder, and now I no longer see the alert. I suppose that makes this worksforme, although shouldn't there be a bug about the index getting out of whack?
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
(In reply to comment #3) > shouldn't there be a bug about the index getting out of whack? "Retry of UID COPY" itself is required for next case. > (A) Mail of the UID exists on IMAP server, but server returned NO to UID COPY. But following can occur, even after WORKSFORME of Bug 465800. (1) Somehow problem of UID COPY error occurs at server, and same phenomenon as this bug occurs. (2) To recover from the error, troublesome mail is deleted at server. (3) Even though (2), phenomenon of this bug continues until rebuild index. I think a way to stop "retry loop" will be required, because it's very annoying and it prohibits following fetch of new mails. Setting Dependency to Bug 465800, or ease of search.
Depends on: 465800
You need to log in before you can comment on or make changes to this bug.