Open Bug 486947 Opened 16 years ago Updated 9 years ago

Simultaneous sending and receiving messages with "Sent==Inbox" causes "There was an error copying the message to the Sent folder, Retry?", and Retry operation produces multiple copies in Inbox(as sent folder)

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

People

(Reporter: samjnaa, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 GTB5
Build Identifier: 

I think this may be related to bug 354064, bug 289869, bug 476263 and/or bug 257735 but I am not sure so I am filing this as a separate bug. Please bear if it is really a duplicate.

One thing I often do is to receive and send messages at the same time when I go online, in my eagerness to get things done. When I do this, the mails in my outbox keep getting prevented from getting saved, and I keep getting the error "There was an error copying the message to the Sent folder, Retry?"

I suspect that it is because my email accounts are of GMail so the sent items folder and inbox are one and when the folder (stored as a file on disk) is locked by the one process (receiving mail) it is unable to be opened by the other process (sending mail).

Reproducible: Always

Steps to Reproduce:
1. Configure your mail accounts.
2. Click the Get Mail button.
3. Right-click on the Unsent folder and send the messages.
Actual Results:  
The outgoing mails couldn't be saved to the inbox (= sent items) folder.

Expected Results:  
Thunderbird should wait for the lock on the file (by either the sending or receiving process) to be relieved and after that allow the other process to lock. Some way of holding the pending changes from the waiting process until the lock is released must be devised.

I have made the severity as critical because it "causes you to lose data".
 Shriramana what version of thunderbird are you using ? And I don't think your issue is covered by the list of bug you gave us above.
I am very sorry I should have specified the version at the outset. I have this bug ever since I upgraded to version 2, and I am now at the latest 2.0.0.21. I will also try out Shredder and see if I am able to reproduce it.
(In reply to comment #0)
>
> One thing I often do is to receive and send messages at the same time when I go
> online, in my eagerness to get things done. When I do this, the mails in my
> outbox keep getting prevented from getting saved, and I keep getting the error
> "There was an error copying the message to the Sent folder, Retry?"
> 
> I suspect that it is because my email accounts are of GMail so the sent items
> folder and inbox are one and when the folder (stored as a file on disk) is
> locked by the one process (receiving mail) it is unable to be opened by the
> other process (sending mail).

so you are using the webmail extension?

Is it possible to set the sent mail box to "Other: inbox" instead of "Sent folder on"?

(I should hack up a gmail+thunderbird account so I understand these things - is there a gmail expert in the house? )
(In reply to comment #3)

> (I should hack up a gmail+thunderbird account so I understand these things - is
> there a gmail expert in the house? )

M-wada seems to be one.
Hello. I now checked on Tb 3 beta 2, and I couldn't reproduce the error, but I am not entirely sure that the error will not exist because I don't trust the method I used to try and reproduce the error (which was successful two times on Tb 2):

1. I sent myself a big mail (with 2 MB attachment) so that it waits in my inbox on the GMail server. It must be big enough that it takes at least 10 seconds to download (so that I can do step 3 successfully).
2. I prepare a test outgoing mail and put it in my local Tb Unsent folder.
3. I start the downloading process and once Tb has authorized with the POP server (my guess is that only after that happens will Tb lock the local Inbox file) I give the command "Send Unsent Messages".

My thinking is that once the download process has been started, Tb locks the Inbox file, and therefore any writes to it by the sending process are unable to be committed. If anyone can do better -- examining the actual code (something I cannot do due to lack of knowhow) -- it would ensure that the bug either exists or not.
(In reply to comment #5)
> Hello. I now checked on Tb 3 beta 2, and I couldn't reproduce the error, but I
> am not entirely sure that the error will not exist because I don't trust the
> method I used to try and reproduce the error (which was successful two times 

Can you keep using TB3 beta2 for the next Month or so and if you have the issue again make sure to comment. Setting the closeme in a month.
Whiteboard: closeme 2009-05-14
(In reply to comment #0)
> (words in bug summary) "sent mail to be lost"
> Actual Results:  
> The outgoing mails couldn't be saved to the inbox (= sent items) folder.
> I have made the severity as critical because it "causes you to lose data".

Does it mean "Retry(OK button) to next dialog never works forever"? Or retry silently fails and no chance to another retry?
> "There was an error copying the message to the Sent folder, Retry?"
See Bug 215044 (pointed in Bug 406929) for issue upon "send unsent messages" when  IMAP Sent folder & IMAP server is down.
To Shriramana Sharma(bug opener):

Question to avoid my misunderstanding.
POP3 server in comment #5 is POP3 of Gmail? Both your comment #0 & comment #5 is for POP3 of Gmail & SMTP of Gmail & Local mail folder? Or Gmail IMAP & SMTP of Gmail & IMAP folder of Gmail is involved in one of them of both?
(In reply to comment #7)
> Does it mean "Retry(OK button) to next dialog never works forever"? Or retry
> silently fails and no chance to another retry?
> > "There was an error copying the message to the Sent folder, Retry?"

I keep getting the above window but it never works. If I say "Yes, retry", I get the window, and even if I say "Don't retry" I get the window about 5-6 times and then it fails silently.

And I also think that the behaviour in bug 215044 which you have pointed out is exactly the same, (surprising that the bug is around for 6 years) but my bug actually notes that the sending conflicts with the receiving in locking.

And in reply to comment #9, it is definitely the POP protocol that is being used, of GMail. IMAP is in no way involved, which is why this bug is not a dup of bug 215044.
Whiteboard: closeme 2009-05-14
When local mail folder, and when it's problem on non-sent-folder(i.e. draft-folder, unsent-message-folder, etc.), and folder for sent-folder is different from folder for draft-folder/unsent-message-folder, "Save As Draft/auto-save" and "Send Later" falls back to folder for sent-folder. And retry is successful, unless folder for sent-folder is unable to use.

See Bug 485348 Comment #3 and Bug 485348 Comment #5 for my test result of "'Save As Draft' fails when compact is in progress on Draft folder, and falls back to Sent folder".
Similar phenomenon(and successful fall back to sent-folder) can be observed by;
(Case-A : fall back to Sent is not interfered)
 (1) Edit file of "Drafts" & "Unsent Messages" by text editor(force write-lock)
 (2) Compose a mail, "Save As Draft" or "Send Later"
 (3) Failure => Retry => Fall back to Sent (tow mails is produced in Sent)
(Case-B : fall back to Sent is interfered temporary)
 (1) Edit file of "Sent" by text editor(force write-lock)
 (2) Edit file of "Drafts" & "Unsent Messages" by text editor(force write-lock)
 (3) Compose a mail, "Save As Draft" or "Sent later" => fall back also fails.
 (4) Close editor window for "Sent"
 (5) Retry => fall backs to Sent => saved in Sent
     Because of multiple error due to (1), fall back is executed multiple times
     => many mails are saved in Sent.

But your case is;
- sent-folder==mail-download-folde=="Inbox", and "Copy to sent-folder(==Inbox)"
  is interfered by "download mail to inbox(==Inbox).
- Failure of "Copy to sent-folder", so fall back to sent-folder usually fails. 

Question to Shriramana Sharma(bug opener):
You set sent-folder==mail-download-folder==Inbox intentionally? If so, what is your purpose of intentional use of such setting?
Or "reply mail to a mail in Inbox" && "following option is checked" case?
  Copies&Folders, "Place replies in the folder of the mwssage being replied to"

> And I also think that the behaviour in bug 215044 which you have pointed out is
exactly the same

I think solution proposed in bug 215044(e.g. asking for fall back folder) is required for your case too.
(In reply to comment #11)
> Question to Shriramana Sharma(bug opener):
> You set sent-folder==mail-download-folder==Inbox intentionally? If so, what is
> your purpose of intentional use of such setting?

I was not aware that there is any difference between mail download folder and inbox. And about setting sent-folder=inbox, I used to do it manually before you introduced GMail as a separate type of account in Tb but after you (Tb developers) introduced GMail as a separate type of account, the sent-folder is automatically configured to be the same as inbox to emulate the GMail behaviour of having both sides of the conversation together.

> I think solution proposed in bug 215044(e.g. asking for fall back folder) is
> required for your case too.

If that means: "save files in this folder if you are not able to save them in any other folder", it would be a stop-gap measure for the present problem (one process does not wait for the lock on the folder by another process to be released), but it is not the proper solution. 

I am only today setting up to use Tb 3 for testing as suggested by the devel who set the closeme and will report if I have continued problems with Tb 3. I mostly think it was (inadvertently?) fixed in Tb 3 which is good.
(In reply to comment #12)
> after you (Tb developers) introduced GMail as a separate type of account,
> the sent-folder is automatically configured to be the same as inbox to emulate the GMail behaviour
> of having both sides of the conversation together.

Following is prefs.js entries defined by Tb 2(Gmail POP3 account).
> user_pref("mail.identity.id3.draft_folder", "mailbox://abc@pop.gmail.com/Drafts");
> user_pref("mail.identity.id3.fcc_folder", "mailbox://abc@pop.gmail.com/Sent");
> user_pref("mail.identity.id3.stationery_folder", "mailbox://abc@pop.gmail.com/Templates");
Tb never sets fcc_folder=Inbox automatically. Did you set fcc_folder=Inbox manually(via text editor, Config Editor, or Copies&Folders setting)?

In both cases(fcc_folder=Sent and fcc-folder=Inbox), auto-compact can produce phenomenon you experienced(similar phenomenon to Bug 485348 Comment #3).
Do you use auto-compact? If yes, do you enable "Confirmation dialog before auto-comact"?
Check prefs.js entries I wrote in Bug 482836 Comment #9.

If auto-compact is reason why "There as an error ... Retry?", next can be said.
 - Cause of your data loss == Your reply of "Cancel of retry"
 - Reason why you don't experience problem with Tb 3 is;
     Tb 3 changed behavior of auto-compact - Don't invoke it while downloading.
(In reply to comment #13)
> Tb never sets fcc_folder=Inbox automatically. Did you set fcc_folder=Inbox
> manually(via text editor, Config Editor, or Copies&Folders setting)?

Maybe. I am sorry but I don't remember. I seem to remember that Tb made it by itself but perhaps I am mistaken. In any case, it is irrelevant if the bug is fixed as you say so.

> In both cases(fcc_folder=Sent and fcc-folder=Inbox), auto-compact can produce
> phenomenon you experienced(similar phenomenon to Bug 485348 Comment #3).
> Do you use auto-compact? If yes, do you enable "Confirmation dialog before
> auto-comact"?

I use auto-compact but I do not enable any confirmation dialog. I will try it.
(In reply to comment #14)
> if the bug is fixed as you say so.

(Slightly Off-Topic)
Please not that "don't invoke auto-compact during download" never resolve problem itself. It'll merely reduce frequency of problem like yours very much, if your problem was caused by auto-compact. Even if possiblity of problem is reduced to nearly equal to ZERO for general users by the change, it never equals to ZERO. If "compact of Sent folder is in progress", "There as an error ... Retry?" can occur upon send. And, there is no way for users to know whether compaction is in progress on Sent or not/when compaction will end.
Hello. Apparently auto-compact was NOT enabled on my system. I manually turned
it on and also set it to ask me a confirmation dialog, by the following two
items in prefs.js:

user_pref("mail.prompt_purge_threshhold", true);
user_pref("mail.purge.ask", true);

However, I still have the problem. I was asked about compacting *after* I lost
my test sent mails. So I guess the suspect is again that the receiving process
locks the inbox file which the sending process then can't write to.

And in reply to comment #15, I clarify that I never get any message like "Compact of sent folder is in progress". I only get "There was a problem saving the message to the sent folder, retry?"
Hello. Now testing with Thunderbird 3 Beta 2. Confirming bug exists. Please remove closeme.

Details:

As MWADA pointed out, Tb (even Tb 3) indeed does not by default set the inbox to be the sent folder. But I want to do so because it enables me to follow both sides of my conversations like on GMail web interface.

And by the same test as I outlined in comment #5, I was able to reproduce the same error "There was an error copying the message to the sent folder, retry?"

What I was previously doing wrong in comment #5 when I could not reproduce the bug was that I was assuming that by default Tb makes inbox as sent folder for GMail accounts, which is not true, as MWADA correctly pointed out. Now that I manually set the Inbox to be the sent folder, I get the bug, and I suspect it is because of the same reason I have been insisting on all along, one process being unable to open a file locked by another.

So please remove the closeme and confirm this bug.
(In reply to comment #16)
> I was asked about compacting *after* I lost my test sent mails.

Thanks for testing. Now it's clear that "auto-compact" is not culprit. Sorry to "auto-compact" for my suspecting.
Tested with Tb2?

(In reply to comment #17)
> Now testing with Thunderbird 3 Beta 2. Confirming bug exists.

If Tb 3, another suspect exists : auto-indexing. See Bug 482836 Comment #26.
Disable (a) when specific test, and disable (b) if you have IMAP accounts, to avoid interfere by these two options or new problem of these new features.
>(a) Tools/Options/General,
>    - Enable Global Search and Indexer
>(b) Account Settings/Syncronization & Storage, Message Synchronizing
>    - Keep messages for this account on this computer

(In reply to comment #16)
> I was asked about compacting *after* I lost my test sent mails.
> So I guess the suspect is again that the receiving process locks the inbox file which the sending process then can't write to.

As I wrote in Comment #11, "There was an error..., Retry?" was issued without "another process is in progress..., wait for please" like message, when I interfered "Save As Draft"/"Send Later" by text editor. I suspect internal file locking related issue such as "write-file-lock", instead of mail folder level locking(mailDB, .msf). I guess, if mail folder level locking, "another process is in progress..., wait for please" like message appears, as when "compact is in progress".
(In reply to comment #16)
> I was asked about compacting *after* I lost my test sent mails.

You lost sent mails because you replied "Cancel" to "..., Retry?", didn't you?
 (download/filterng & move/auto-compact)          (mail sending)
  A                                                Send mail to SMTP server
  | Download to Inbox             <-+-contension-> Copy to sent-folder(==Inbox)
  | Mail move from Inbox          <-+              => "..., Retry?"
  |  to other mail folders                         Reply OK
  |  by message filter/Junk filter  <-contension-> => Retry of copy
  V                                                   => "..., Retry?"
  Condition of auto-compact happens
  (If parg.ask=true, dialog before auto-compact)
  (If reply OK, auto-compact starts            )
  A                                                Reply OK
  | Auto-compact runs on Inbox      <-contension-> => Retry of copy
  V                                                   => "..., Retry?"
  Auto-compact ends                                Reply OK
                                                   => Retry of copy is successful
Version: unspecified → Trunk
I am sorry but you lost me with that flowchart, since I am almost totally ignorant of the internals of Thunderbird.

In response to your comment #18, I repeat that I have tested this bug in both Tb 2 and 3 with the same procedure outlined in comment #5 and confirmed that the bug exists. I also repeat my suspicion that this is some kind of locking issue. 

If you ask me anything more technical than that (as to whether it is auto-this issue or auto-that) I am sadly ignorant of how to understand your question or how to reply to it. Thank you for your patience. I only request that the developers find out the actual reason for this bug and fix it.
My asking was:
(Q1) Please see that flowchart.
(Q2) I think sent mail is saved in Inbox, if you reply OK to "..., Retry?"
     after auto-compact ends, or auto-compact is not executed.
     Is it right?
 (A) Cancel to "dialog before auto-compact" case.
     1. Wait for a while, and check mails in Inbox.
     2. If Inbox is normally accessed, reply OK to "..., Retry?".
     3. If "..., Retry?" is displayed multiple times,
        reply OK to all "..., Retry?".
 (B) OK to "dialog before auto-compact" case.
     0. Measure time for "compaction of Inbox" first, by "move a mail in Inbox
        to other folder then move back" + "manual compact folder of Inbox".
     1. When problem occurs again, wait for a while(longer time than (0)),
        and check mails in Inbox.
     2. If Inbox is normally accessed, reply OK to "..., Retry?".
     3. If "..., Retry?" is displayed multiple times,
        reply OK to all "..., Retry?".

Above is new version of my following question in Comment #7.
> Does it mean "Retry(OK button) to next dialog never works forever"?
> Or retry silently fails and no chance to another retry?
> > "There was an error copying the message to the Sent folder, Retry?"
Hello. I think you have not seen properly my comment #16 in which I say that auto-compact has absolutely no effect on this bug. So unfortunately your meticulous analysis is shooting up the wrong alley, since you do not consider what I said before: the problem here is that the downloading process locks the inbox file and hence the send process cannot access file.

Can anyone else please look into this? Friend Mwada does not appear to consider my side of the argument. (No offence to Mwada.)
(In reply to comment #22)
> I think you have not seen properly my comment #16

Who said that "(auto) compact folder" is culprit of first "Retry?" dialog in your case after your comment #16?
Key points of flow chart in comment #19:
(1) Contention is between "Inbox(for download)" and "Inbox(for sent mail)".
    So "dialog before auto-compact" appears after "Retry?" dialog.
(2) If auto-compact is enabled, it can force some retries to fail.
    It'll help to see when retry becomes OK.

(for your side of argument:1)

My comment #19 and comment #21 is for your "data loss" & "Severity:critical" part.
   When "retry of saving of sent mail(=to Inbox in your case)" becomes OK?
   Retry is never successful? (fails even after end of auto-compact?)
   I think "No saved sent mail" occurs only when "No" is replied to "Retry?"
   dialog. Is it wrong?
   (Note: It's third question for same thing.)    

(for your side of argument:2)

Same phenomenon is already reported for next case to older bug, except "data loss" part by you.
>  (A) Account Settings/Copies&Folders
>      When sending messages, automatically:
>        [x] Place replies in the folder of the message being replied to
>  (B) Big Inbox. Further, "Leave Messages on Server" is enabled.
>  (C) Reply to mail in Inbox and send mail => sent mail is saved in Inbox 
In above case, "saving of sent mail(to Inbox)" is interfered for long time by any of mail download, auto-compact of big Inbox, internal rebuild-index of big Inbox, etc. AFAIR, no request like your "Expected Results:" was made in that bug.

As you say, "simultaneous update of MsgDB by download and sent-mail-copy" is better to be enabled. (Note: If Severity=Enhancement, I think it's a reasonable request.)
But I guess that current "Inbox level locking during download" is a result of code change to avoid MsgDB corruption due to "simultaneous update by download and other operations such as sent-mail-copy" in the past. 
So, as you wrote in "Expected Result:", I feel changing "Retry? dialog & Execution of retry if OK response" to mechanism such as "Queuing of sent mail saving request" is a practical solution.
  Note-1:
  If Severity=Enhancement, I think it's a reasonable request, although I believe
  "Inbox != Sent" is simplest/easiest solution for many many general users.
  Note-2:
  It can do nothing when IMAP case and server down after first save error.
  So "final fall back" like feature is also required even after the new
  mechanism will be implemeted.
And I think "Fall back to other folder"(already requested in other bug) can be a solution for issue of "no saved mail when 'No' to 'Retry?' dialog".
However, if something wrong exists in your "contention between Inbox & Inbox" case, and if it'll never be resolved, even such new mechanism won't work. So I tried to rule out "never successful retry of save" case.
But still no answer from you about it...
"Gmail" is Gmail POP3? Or Gmail IMAP?
If intentional "folder to save sent mail == Inbox" && Gmail IMAP case, "locking" can occurs at "IMAP task level" too.
  - Download : SELECT Inbox, FETCH from Inbox, <= IMAP task level
               and update MsgDB for Inbox.
  - Mail send: Pass data to SMTP server.
               SELECT Inbox if not selected, or tries to use session for Inbox
               if session for Inbox is already opened. <= IMAP task level
               (it's because of your intentinal setting)
               APEND to Inbox, and FETCH from Inbox,   <= IMAP task level
               and update MsgDB for Inbox.
It may be reason why no "another process is in progress..., wait for please" like message in your case.
Further, if IDLE support is enabled, interfere of "saving of sent mail to Inbox"
by new mail notification for Inbox via IDLE can also occur.
@Wayne Mery: Thanks for the wake-up call. I had not realized that this thread had been updated. The mail must have been lost in my inbox.

@MWADA: I am very sorry but I am unable to follow your comments. Maybe I lack the sufficient technical knowledge. I could understand:

"Queuing of sent mail saving request" is a practical solution.

and I approve of it. I could not comprehend the other parts of your comments because it is too technical for me.

I can only repeat that I am now using the latest Shredder nightlies and still seeing the same bug to be reproduced by the exact same steps in comment #5. Please did anyone else try reproducing the bug using the same steps? Wayne Mery, anyone?
Phenomenon of "'Retry or not' dialog upon mail send due to contention if Sent==Inbox" is already known phenomenon by other some bugs. Shriramana Sharma(bug opener), this bug's particularity is "sent mail to be lost" in bug summary by you. I couldn't see such report in other bugs. If user replies "Retry", "OK" or something like that, sent mail is saved in sent folder(folder of Inbox in this case) finally. "Sent mail is not saved in sent folder(==Inbox in this case) occurs only when "Cancel of retry"(==no need to save any more) is replied by user. So I asked about it repeatedly.

Question again.
Did "copy of sent mail was not saved" occur even though you didn't reply "Cancel" or "No" or something like it?
You did reply "Cancel" or "No" or something like it(==no need to save any more), didn't you?

By the way, your test case seems one of best scenarios to observe phenomenon due to contention of mail folder which is caused by "Sent==Inbox". Your case looks to be able to reproduced problem easily, repeatedly, frequently, almost reliably.
sorry, I did not test. leaving that to others who know gmail better. but I do use sent == inbox in imap.

in any event, this is likely a dupe.
Summary: Simultaneous sending and receiving messages causes sent mail to be lost → Simultaneous sending and receiving messages causes sent mail to be lost with Sent == Inbox - "There was an error copying the message to the Sent folder, Retry?"
> Question again.
> Did "copy of sent mail was not saved" occur even though you didn't reply
> "Cancel" or "No" or something like it?

Yes I hit cancel because the window kept coming back every few seconds if I hit retry. But that did not really help me because the window kept coming back every few seconds (for about 20 times) even if I hit cancel.

> You did reply "Cancel" or "No" or something like it
> (==no need to save any more), didn't you?

Basically I felt it was the only way to close the window. 

I know that I cannot complain of mail having been lost when I have explicitly told the computer to cancel trying copy of sent mail to sent folder. 

So if I try to keep hitting "retry" or at least wait until the downloading operation is complete, *then* what happens? Well my testing this just now turned up a crazy behaviour. Even after the incoming mail has been fully downloaded, I have to hit "retry" about five times after which the window closes. Now I find that in my sent folder, the same outgoing test mail (which I sent at the same time of the downloading of the big incoming mail) is saved in the sent folder *five times*. Better than nothing, I suppose, but still not ideal behaviour.

It is crazy that I have to either hit "Retry" umpteen times or "Cancel" umpteen times to get the window to close. It is obvious that the operation which is trying to move the sent mail from the outbox (or drafts) to the sent folder does not wait for the incoming mail process to complete. 

As you said, the proper approach to the solution of this is to queue the operation of moving sent mail to the sent folder to be started after the downloading job is done when the inbox == sent items.

But even apart from this, I think that the application, having failed to move the sent mail to the sent box, should not send it to oblivion. It should either retain it in the outbox (maybe not a good idea) or the drafts (somewhat harmless but not ideal) or a backup sent folder (best idea).
(In reply to comment #28)
> Well my testing this just now turned up a crazy behaviour.
> Even after the incoming mail has been fully downloaded, I have to hit "retry" about five times after which the window closes.
> Now I find that in my sent folder, the same outgoing test mail (which I
> sent at the same time of the downloading of the big incoming mail) is saved in
> the sent folder *five times*.
> Better than nothing, I suppose, but still not ideal behaviour.

Thanks for answer of "no data loss if Retry is replied", and detailed report of Tb's current crazy behaviour for user in your case. Even if "no data loss if Retry is replied", Tb's behaviour should be improved.

Single mail in "Unsent Messages" folder case?  Or multiple mail case?
Multiple "Retry or Cancel" dialog was displayed at same time? Or "Retry or Cancel" was displayed serially? (When Retry is replied, next "Retry or Cancel" was displayed.)
(In reply to comment #28)
> (i) It should either retain it in the outbox (maybe not a good idea)
> (snip) or (ii) a backup sent folder (best idea).

"local back up sent folder" like your (ii) is already requested, because there is no way to save copy of sent mail if long time IMAP server down.
Similar option to (i) is being discussed, because "background mail sending" is already implemented for Tb 3. If "background mail sending", "mail send failure" can occur in addition to "save to Sent failure", and dialog of "Retry or Cancel" can do nothing in many cases.

By the way, there is another solution: Prohibit setting of "Sent==Inbox" :-)
Removing "sent mail to be lost" from bug summary, and confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Simultaneous sending and receiving messages causes sent mail to be lost with Sent == Inbox - "There was an error copying the message to the Sent folder, Retry?" → Simultaneous sending and receiving messages with "Sent==Inbox" causes "There was an error copying the message to the Sent folder, Retry?", and Retry operation produces multiple copies in Inbox(as sent folder)
(In reply to comment #29)
> Single mail in "Unsent Messages" folder case?  Or multiple mail case?

I tested with a single outgoing message. Same would obviously happen with many. In my previous comment I meant "the single message is saved as many times as I press Retry".

> Multiple "Retry or Cancel" dialog was displayed at same time? Or "Retry or
> Cancel" was displayed serially? (When Retry is replied, next "Retry or Cancel"
> was displayed.)

Serially.

(In reply to comment #30)
> By the way, there is another solution: Prohibit setting of "Sent==Inbox" :-)

Please don't do that!
BTW I think it would be elementary for anyone to reproduce this bug. The steps
to reproduce I have outlined in comment #5 above are not very difficult to
imitate. Only that you have to have a sufficiently big mail in your inbox to
take at least some time to download so that there is time for:

1. you to right-click on Unsent box, 
2. you to click "Send unsent" 
3. the program to connect to and authorize with the SMTP server 
4. the program to actually send the Unsent mail via the SMTP server 
5. the program to try to save it in the Sent mail folder.

If someone has a much faster net connection than mine, they would need
something like 10 MB or maybe more in the incoming "big mail" to follow the
steps correctly.
FYI.
Bug 390136 is the other bug for "Sent==Inbox" case.
Component: General → Backend
Product: Thunderbird → MailNews Core
QA Contact: general → backend
rkent, irving, are you able to do anything with this race?
(In reply to :aceman from comment #37)
> rkent, irving, are you able to do anything with this race?

This is the class of problems that maildir is supposed to solve. I would rather spend my time getting maildir working, than trying to fix all of the edge cases where mbox fails.
OK, but do we drop mbox once maildir-lite is ready?

Reporter: Maybe as a temporary workaround, you can try to add a filter running on messages being sent (yes, an extension is needed for now) that matches all messages and moves them to the Inbox folder. But I don't know if that is more reliable or works in this scenario.
You need to log in before you can comment on or make changes to this bug.