User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:18.104.22.168) Gecko/20091221 Firefox/3.5.7 Build Identifier: 3.0.0/3.0.1 I've experienced this problem twice now with Thunderbird 3, firstly with 3.0.0 and secondly with 3.0.1. When you move multiple files from 1 folder to another it 'appears' to have worked fine however upon closing and reopening Thunderbird it has actually created 1000's of duplicate emails. This latest incident has created 38,000 duplicates, after reopening Thunderbird it proceeded to download the 38,000 new emails however when I checked the mail folder on the server it appeared to be continuing to create duplicates (up to 40,000). The first time this happened I had to spend hours manually deleting the duplicate emails, this time I have 4x the number of duplicates, and I dare not reopen Thunderbird in case it starts to create more. This situation is ridiculous, my email account is now completely unusable. What am I supposed to do now (besides look for a new email client)? Reproducible: Always Steps to Reproduce: 1. Move emails in volume Actual Results: Massive email duplication. Expected Results: Move emails to a different folder.
Move to IMAP folder of same account? Or to folder of different IMAP account? I assume former. Move mails from IMAP folder to other IMAP folder of same account consists of; uid copy to move target folder, uid store Flag \Deleted at source folder I don't know "uid copy" for all UIDs is issued as single command or is issued as multiple command by Tb. If "uid copy xxx:yyy target-folder" is issued by Tb but the response for the command is not returned within time Tb expects, next can happen. - server exeecutes "uid copy xxx:yyy target-folder". - Tb thinks "uid copy xxx:yyy target-folder" fails. This mismatch can produce multiple copies at move target folder. A cause is too small tcptimeout value for such command which takes very long. Other cause is Tb's retry logic. AFAIK, Tb retries it too many times. AFAIR, enhancement request like next exists; Split "uid copy" command to multiple "uid copy" commands, Increase tcptimeout automatically if retry, Limit retry count (it may be "one retry", I'm not sure though) Anyway, get IMAP log with timestamp, and check IMAP level flow. > https://wiki.mozilla.org/MailNews:Logging > http://www.mozilla.org/projects/nspr/reference/html/prlog.html#25328
I experienced the same problem using Thunderbird 3.0.1. on WinXP. When trying to archive approx. 6000 emails (by pressing 'a') I ended up with approx. 30000 emails. It's an IMAP account, so I think this is equivalent to the above mentioned problem of moving emails from one folder of the same account to another.
I've seen this happen a few times when moving a *lot* of messages at once (6000 is a *lot*)... I this this is a combination of a client *and* server problem. It's always been with a courier-imap server when I've seen this. Another problem is if the person moving them starts doing other things before the move is finished. Moving 6000 messages at once on a courier-imap server could take as long as 30-60 seconds, and if you start clicking on other folders/messages before it is finished moving them, you will end up with lots of duplicates like this. One big problem is the lack of visual feedback about what TB is doing. Also, I think there should be some kind of threshhold (number of messages) that, if exceeded, will cause the move to be blocking - ie, a dialog comes up that says something like 'Please wait while Thunderbird completes this operation', and doesn't let you do anything else until it is finished. The work-around is: 1. Don't move so many at once, and 2. Wait until it is completely finished before doing anything else You know its done when the messages disappear from the current folder *and* the next message that gets automatically selected is fully loaded. Incidentally, in my experience TB2.0 was much worse about this than 3.0...
undercover problem is the same => dupes bug #296453
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 296453
You need to log in before you can comment on or make changes to this bug.