Closed Bug 206408 Opened 21 years ago Closed 17 years ago

spin when copying message to "Sent" folder

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: aleksander.adamowski, Assigned: Bienvenu)

References

Details

(Whiteboard: please do not comment: see comment 266, comment 276)

Attachments

(14 files, 1 obsolete file)

a screenshot of this
78.73 KB, image/jpeg
Details
fix for copying folders case
996 bytes, patch
sspitzer
: review+
mscott
: superreview+
sspitzer
: approval1.6b+
Details | Diff | Splinter Review
make cancelling imap fcc really cancel
11.76 KB, patch
sspitzer
: review+
mscott
: superreview+
sspitzer
: approval1.6b+
Details | Diff | Splinter Review
A workaround for spin on copying message to "Sent" folder
94.87 KB, image/jpeg
Details
Logfile for IMAP access
8.50 KB, text/plain
Details
Extract of Log
32.20 KB, text/plain
Details
Backtrace announced in comment 129
22.73 KB, text/plain
Details
duh, wrong patch...
1.47 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
[checked in]saving some work that handles cancelling of multiple fcc's
4.93 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
Stuck on Sending Authenticate Information dialog box
25.60 KB, image/jpeg
Details
server side imap capture
1.27 KB, text/plain
Details
Client side TB log
7.27 KB, text/plain
Details
Example of e-mail that triggered the spinning - real addresses substituted, char for char
1.08 KB, text/plain
Details
Screenshot of spinning - for Example e-mail that triggered the spinning
9.42 KB, image/jpeg
Details 
This is a follow-up to bug 185677.

Bug is very hard to reproduce reliably, but exists beyond doubt.
The latest version I've seen this bug with was trunk 2003051522.

The symptoms: when sending a mail message, MailNews hangs after sending while
trying to save the message to the "Sent" folder. The "Copying message to Sent
folder" is on screen, waiting for numerous minutes doesn't help.

The bug seems to be network-unrelated, as the problem has occured with IMAP,
POP3 and Local folders.

The problem sometimes goes away after few hours/days/Mozilla restarts, but no
pattern is visible.


Today with aforementioned build I've had this problem on IMAP, but it went away
after a restart. I had the option "Check this folder for new messages" selected
for my "Sent" folder on IMAP, this might be the cause, so I've unchecked it and
am waiting if the problem will return.

TYhe workaround is to cancel the "Copying..." operation and close the message,
then answer "Save" when asked whether to save to Drafts. Then move the message
from Drafts to Sent.

BTW, the problem sometimes prevents copying message to the target folder...
this looks like a dupe of bug 89285. (and bug 197102)
Did unchecking  "check this folder for new messages" for the Sent folder make
the problem go away?
No, it didn't.
This is a dupe of bug 89285 indeed. Marking as such.

*** This bug has been marked as a duplicate of 89285 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20030924

I get the same message. It just stays there. When I look into the sent folder,
it is displayed empty, for sure it is not; the hourglass is shown, though.

Reopening, I have it -- also as originally reported -- with POP3. My mail
folders are mounted over NFS.

I don't know where "check this folder for new messages" is.

pi
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I missed to say: The mail was sent (arrived) and actually shows up in the sent
folder after restarting mozilla.

I feel (but have no evidence) that this has the same reason as why I see bug 90422.

For now it would be very useful to have some clear output why a message cannot
be written to the database.

pi
"check this folder for new messages" is available when you select "properties" 
for the folder off the folder tree.
Ion, this does not exist for me.

pi
Attached image a screenshot of this — 
this is a quite obvious screenshot of this bug.
Boris is using POP3, not IMAP. If anyone is using IMAP, I've heard that this is
working much better in 1.6a for some users.
Component: Mail Database → Composition
I have been seeing this problem as well on 1.5 release version on Linux, with
Sent as a Local Folder (so can't unselect "check this folder for new messages").
 Typically closing Mozilla Mail and reopening will fix, and the message will be
in the Sent folder.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029

This in my opinion is the most severe bug in Mozilla and has been for about 2
months or more up to 1.6a
It happens after a while of having Mozilla open, and it fixes by restarting
Mozilla.  

I am using IMAP but the problem is always when saving to my Local Sent folder, I
mean I think it is unrelated to IMAP since I have the account configured to save
sent messages locally. I do have another IMAP account which saves sent messages
in the server but this never happened with that account.

Most of the time I can't even save the message because after the copying stalls
and I cancel I can't even save it to drafts, I don't recall the error but it is
quite non-specific.

Someone suggested better error reporting when copying/saving messages fail, I
believe that would be a good start.  Is there any progress being made?
Alonso, I can't reproduce this problem. Do you have any idea what steps cause
this problem? Do you ever send two messages at the same time? Do you have
filters that move messages to the sent folder? You say once this happens, you
can't save messages to the draft folder either? Is that a local drafts folder?
The text of the error message might be helpful. Once you're in this state, can
you click on the sent folder and see what happens? How big is your sent folder?
>Alonso, I can't reproduce this problem. Do you have any idea what steps cause
>this problem? 

David, I also have this problem, but there is absolutely no action which seems
to cause it. It just happens.

>Do you ever send two messages at the same time? 

I don't, since I work online. It happens when I compose just one message or when
I compose two, but that should not affect the sent folder.

>Do you have
>filters that move messages to the sent folder? 

I don't.

>You say once this happens, you
>can't save messages to the draft folder either? 

It is not accessible at all. You cannot even display the content. The hourglass
shows, but not a single message.

>Is that a local drafts folder?

I don't use any local folder, it is all in normal account folders.

>The text of the error message might be helpful. 

It is just what was cited above.

>Once you're in this state, can
>you click on the sent folder and see what happens? 

As I said above, you cannot see anything there.

>How big is your sent folder?

The messages of one day, just a couple.

pi
Do you ever get a message about copying to the sent folder failing? Also, Pi,
there's no reference to an actual error message in any of the comments that I
can see, just that we starll with "Copying message to sent folder".

When I say local folder, I mean local to your machine as opposed to imap folder,
so folders in your pop3 account are "local"

>>You say once this happens, you
>>can't save messages to the draft folder either? 

>It is not accessible at all. You cannot even display the content. The hourglass
>shows, but not a single message.

this happens to both your Sent and Draft folders at the same time? Or did you
think I was asking about the Sent folder?

OK, I've managed to recreate this in the debugger by simulating failures in a
bunch of places and seeing if they cause this problem. I now have a pretty good
idea where it's failing for you. 

nsMsgLocalMailFolder::CopyFileMessage, probably in CopyData(inputStream,
(PRInt32) fileSize); though I don't know why that would fail. But if I pretend
that fails, I see the same problems you see. We're not sending an EndCopy in
that case, so we're not cleaning up after ourselves. I'll try to figure out how
to handle this, and how it could be happening in the first place.
Summary: Hang when copying message to "Sent" folder → spin when copying message to "Sent" folder
Ok, I see some progress, nice. I answer below just in case it's still needed:

<Do you ever send two messages at the same time?
No
<Do you have filters that move messages to the sent folder?
No
<You say once this happens, you can't save messages to the draft folder either?
What happens is the program just hangs saying it's trying to copy to Send
folder. Then if I click on cancel the composing window is left in some weird
state were it can't be saved, but if I close the window it then asks if I want
to save and if I say yes the message is saved correctly in Drafts.

<Is that a local drafts folder?
All are local folders, not POP not IMAP.

<Once you're in this state, can you click on the sent folder and see what happens?
Nothing it seems to be trying to read it but it doesn't display anything.

<How big is your sent folder?
The first time I saw this bug I completely cleared the folder to see if that
helped (didn't). I now have 800 messages... yes this has been bugging me for a
while.

Thanks a lot for working on this.
If I was to answer the questions in the previous comments, mine would be
identical. I have relatively high volume (100+ incoming messages/day, approx.
20+ outoing/day) and leave Netscape open the whole day at work.

I also see a problem where I try to delete an email from my IMAP Inbox, and
Netscape does nothing.

In both cases (fail to save sent message to sent messages folder, and delete
from IMAP inbox) a restart fixes the problem, but the errors do occur
separately, ie. I can have one problem but not the other.

I use NS7 at home and have never seen the same problem there, but although I
have IMAP folders configured I rarely use them (receiving by POP instead).

Regarding size of Sent folder, I typically clean mine out by moving to
sub-folders, but as a precaution have moved this sub-folders elsewhere to see if
this has any effect.
Was it intended that the summary was changed from 'Hang ...' to 'spin ...'. As a
user (who would be potentially looking for this bug) hang makes more sense to me
than hang (although I can understand the difference and acknowledge that
*technically* spin is more appropriate).
hang means the app is dead, unresponsive in every way.

> When I say local folder, I mean local to your machine as opposed to imap folder,
> so folders in your pop3 account are "local"

Local on a NFS-mounted directory.

>>>You say once this happens, you
>>>can't save messages to the draft folder either? 
>>
>>It is not accessible at all. You cannot even display the content. The hourglass
>>shows, but not a single message.
>
> this happens to both your Sent and Draft folders at the same time?

No, only to the Sent folder.

> Or did you think I was asking about the Sent folder?

Right. I misread that.

pi
I've made some progress, but I"m still stumped about the root cause. I know that
mCopyState is getting set on the destination folder (the sent folder) and not
getting cleared. That accounts for the symptoms. But I'm not sure what's causing
that. It's possible that it's a problem in nsMsgCopyService::FindRequest, when
we're trying to clean up the copy request and don't find the matching request.

Once you get in this state, does deleting a message (any message) ever get you
out of the state? That would indicate a stalled request.

I'm not sure how to even work around the problem. One possibility is to take
advantage of the fact that fcc is a synchronous copy for local folders and not
set the copy state at all, or to note that it's synchronous, so it shouldn't be
left around, ever...
Status: REOPENED → ASSIGNED
Bienvenu you weren't addressing your questions to me but my symptoms match -
regarding your comment about being stumped on the root cause, is it potentially
related 3 types of simultaneous 'filing' events: deleting an item, sending an
email (and copying to sent) and Junk Mail controls sending email's to the Junk
folder? These are the 3 types of action I see fail (IMAP inbox and Trash, Local
Trash, Junk and Sent folders). Sorry if this is stating the obvious but I have
been seeing this issue for a long time and reproduce the problem multiple times
per day.

Regarding clearing the problem - I am sometimes able to do this but it is not
easy to always do so - restarting is the easiest method and given the amount of
times it occurs is most practical. Not sure if clearing the problem doesn't lead
to the problem recurring again more quickly either. Will try to clear problem
over the next few days to see if I can get a reproducible workaround.
I am seeing less of this bug in the last few days, the only change I've made is
I solved a problem I had with my IMAP server.

I will explain first the problem I had. The IMAP server was configured to allow
only 4 concurrent connections fom each IP address. Since I have two separate
imap accounts and several folders, Mozilla would quickly use up the 4
simultaneous connections and then when I sent an email I got an error when
Mozilla tried to save it to the IMAP Sent folder (because it had run out of
connections the server would not allow it).

Ok so I raised the number of allowed connections and solved that issue.

The weird thing is I am having the spin problem on my local Sent folder not on
the IMAP Sent folder where I was getting the errors. So I don't know if there is
any connection here, but I still wanted to inform you guys.


Some more info. It happened only once today. I did not have any problems saving
to IMAP folder so my previous comment could be way off. Something interesting
which I think no one has said is that it seems after the spin and restarting
mozilla and going to the local Sent folder, Mozilla rebuilds the summary file.
This may be invisible (too fast) if you have a few messages.
I spent some time looking through the code when I was at a place w/o an internet
connection and I discovered that if you copy a folder into the trash folder, so
that the copied folder ends up as sub-folder of the sent folder, you will then
have this problem. Do any of you notice a correlation between copying folders
and this problem? Or perhaps copying messages from imap to local or something
like that? Remember that the state that's getting confused is a per-folder
state, and it should be the destination folder (for messages, the folder itself,
for folders, the parent folder) that gets confused/locked.
 David, please show me exact steps to reproduce.  I do not copy folders around
but messages could be, I routinely copy from IMAP to my local trash folder. I
will watch out for this.
No, I don't see a real correlation with trash'ing folders. I generally don't
trash folders.
here are reproducible steps:

1. copy a local/pop3 folder from one account to the sent folder of another
account, so that it becomes a sub-folder of the sent folder on the other account.

From this point on, you won't be able to have messages fcc'ed to that sent folder.

I don't know if any of you are seeing that problem, but that's the one
reproducible case I have.
in the copy folder case, we were not clearing the copy request, which
essentially locks the destination parent folder.
Attachment #136120 - Flags: superreview?(mscott)
I never move or copy folders, I only have one account (POP3). No filters to the
Sent folder. I once in a while move a message from Sent to another folder, but
this is not related to the problem.

pi
Comment on attachment 136120 [details] [diff] [review]
fix for copying folders case

do you think this should be on the 1.6b train david?
Attachment #136120 - Flags: superreview?(mscott) → superreview+
yes, I do. I need to find a reviewer first...perhaps Seth.
Comment on attachment 136120 [details] [diff] [review]
fix for copying folders case

r/a=sspitzer
Attachment #136120 - Flags: review+
Attachment #136120 - Flags: approval1.6b+
I was able to reproduce this type of problem when fcc'ing to an imap sent folder
and unplugging my network connection in the middle of the copy to the sent
folder. I'll investigate more tomorrow. (Yes, I realize some of you aren't
fcc'ing to an imap folder but I'm going to keep fixing the problems I can
reproduce...)
fix for copying folders case checked in.

for the imap fcc case, I've determined that the cancel button has no effect, so
it won't cancel the copy to the sent folder, leaving the sent folder locked.  
I'm going to try to figure out a way to cancel the fcc request when cancel is
pressed.          This may or may not be applicable to the local folder case,
which is different because the fcc operation is completely synchronous.
this hooks up cancel in the fcc to imap folder case (it did nothing previously
- the fcc continued until it finished)
Attachment #136340 - Flags: superreview?(mscott)
Comment on attachment 136340 [details] [diff] [review]
make cancelling imap fcc really cancel

sr=mscott

David, can you do a quick leak check to make sure we don't leak the msg
progress window when canceling from mail compose? Just want to make sure the
nsIMsgWindow object it now owns gets released :)
Attachment #136340 - Flags: superreview?(mscott) → superreview+
Comment on attachment 136340 [details] [diff] [review]
make cancelling imap fcc really cancel

r/a=sspitzer
Attachment #136340 - Flags: review+
Attachment #136340 - Flags: approval1.6b+
I'll check that before I check in - I also fixed a couple comment nits of Seth.
FYI.. I have the exact same problem.  Using both 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
and 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

This occurs when accessing my remote courier-imap server using SSL/TLS and
sending mail.  The "spin" occurs after sending the mail and shows the "Saving
message to Sent Items" progress dialog indefinitely.  After cancelling it will
sometimes allow me to save to Draft and others it will "spin" again while saving
to Draft.  The message is almost always sent correctly but sometimes the copy
will appear in the Sent folder after restarting and others it will not.

I have noticed that this often occurs when leaving mozilla open for any length
of time and I can often avoid the problem by making sure to "open" the Sent
folder (by clicking on it) prior to sending the message.  I have a sneaking
suspicion that this has something to do with the imap connections expiring or
the number of connections but haven't been able to find the right mix..  My
"connections per IP" setting on the server is plenty high..
-Ken
Still happening in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b)
Gecko/20031210. After restart the messages are there, though.

pi
I had this spin problem using Thunderbird build 20031205 on Windows XP. This
image was actually taken from a version of Netscape Communicator, but people
were having the same problem. I know it's stupid, but in the account
preferences, instead of selecting the appropriate "Sent" folder, select
"Other," and select the same "Sent" folder. It works.
Aaron, does copying to the sent folder *always* fail when you have the pref set
the first way or just fail sometimes? 
David,

 As with most comments for this bug, it only occurs occasionally and does not
seem to be preceded by anything in particular. When it does occur, if you exit
Thunderbird, it still exists in the Task Manager and must be forced to
terminate. Even that does not always fix the problem. Restarting the computer
was the only other option, before I found this workaround.

Aaron
Comment on attachment 137753 [details]
A workaround for spin on copying message to "Sent" folder

Well. I just got my first spin even after trying this workaround. ****.
To Comment #44 by Aaron Milstein :
> Thunderbird, it still exists in the Task Manager
> and must be forced to terminate.

I am experiencing similar situation after termination of Mozilla on Win-Me.
  "Rundll32.exe" task still have connection to mail servers
  and news servers even after termination of Mozilla/THunderbird.
This task seems to be unterminated "Automated Downloading" tasks on temination
of Mozilla/Thunderbird.
See posts by "SoaRex" and "Guest", which were posted by me, in
http://forums.mozillazine.org/viewtopic.php?p=304895#304895.

On Win-Me, this unterminated tasks seems to be canceled on restart of
Mozilla/Thunderbird and this cancel seems to cause problem of above thread,
inconsistency in ".msf" file and rebuilding of ".msf" on restart.

Can you check what is the unterminated task?
 - What is the module running in the task? 
 - Are there any TCP/IP connection to mail server from the task?
*** Bug 231999 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114
and
Mozilla Thunderbird 0.4 (20031205)
on SuSE 8.2
both show the same problems as described by other users but with some additional
twists.  After this bug appears (and I can't predict when it appears), every
subsequent send will behave the same way, and I cannot access my Sent folder in
any way.  I can access other folders on other accounts, however if I try to
close the main mail window, the whole thing hangs pretty hard.  A normal "kill"
will close it though (-9 not required).  This is in fact the primary reason I
switched to thunderbird: so I can kill it when it crashes and not have all my
web browsers go down too (on Mozilla Mail, all the web windows hang as well).  I
can't find any other users reporting this hang though.

My setup:
3 accounts on 3 different IMAP servers.  All folders are on servers (none local).
2-3 Mozilla or Thunderbird clients (home, work, laptop, etc) hitting them at any
given time.. identical setups on all.
Of the 3 IMAP accounts, only one ever produces this problem: po9.mit.edu.
Nothing seems to make po9 very different from the other two... po9 uses SSL, but
so does one of the other servers (hm... actually I never send mail from that
other server).
No filters moving things to my sent folder (one filter moves things to Trash). 
Only a few dozen messages (a day's worth) in those folders at any given time
(and I do "compact" them regularly).

This bug occured for me at some Mozilla version prior to 1.3, but stopped in
1.3, and reappeared in Moz 1.5-1.6 / Thunderbird 0.4.  I've seen it on OSX too.
Danny, other people have had the exact problem with the mit imap server. I've
been trying w/o any luck to get access to a test account on one of these servers
so I can try to reproduce the problem. My belief is that the server does not
realize when we've sent it all the data we're going to send it for the IMAP
Append, and sits there waiting for more data. One trick you can try in 1.7 is
bonking the offline button, which will cause us to send a LOGOUT to the server,
which will suddenly make it realize it's got the data it wants for the APPEND,
and lets the APPEND finish.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I am another MIT IMAP user (po14.mit.edu) who has the exact same problem.  In
fact, it got much worse under Mozilla 1.6.  It used to happen once a week, but
now  it happens almost every time I send an email over a certain length (so,
several times a day)  The email needn't be not very long either: any quoted text
in the mail seems to trigger the problem.  I also used to (in 1.5) be able to go
offline and back online to fix the problem; now, I have to close the window of
the email trying to be copied, close the mail program and close all web browser
windows before I can copy any more mail to the sent mail folder or even access
my sent mail folder (it's an IMAP folder). 

I tried Thunderbird, but it has the exact same problem.  Let me know if I can be
of any assistance in fixing this bug; or, if it is particular to MIT, what I
should ask them to change.  It cannot be entirely MIT's fault, though, or it
wouldn't have gotten much worse once I downloaded 1.6.

Thanks! Ezra
Ezra, all signs point to this being a bug in the cyrus imap server, v2.1.5.
We've tried it against the latest cyrus server and it doesn't have this problem.
A cyrus imap server developer confirmed that there was a problem with early 2.1
versions of the server with network buffers not getting flushed, and thus the
server hanging waiting for more data when the client had already sent the data.

FWIW, the developer sent me the following comment and patch:

"FWIW, this *may* be the fix to the problem, but its been a while since I
looked at it at all:

sourcefour:i386_rh80:/afs/andrew/system/src/local/cyrus/048/imap> cvs diff
-r 1.438 -r 1.439 imapd.c
Index: imapd.c
===================================================================
RCS file: /afs/andrew.cmu.edu/system/cvs/src/cyrus/imap/imapd.c,v
retrieving revision 1.438
retrieving revision 1.439
diff -u -r1.438 -r1.439
--- imapd.c     18 Aug 2003 20:35:38 -0000      1.438
+++ imapd.c     22 Aug 2003 16:31:42 -0000      1.439
@@ -38,7 +38,7 @@
  * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */

-/* $Id: imapd.c,v 1.438 2003/08/18 20:35:38 rjs3 Exp $ */
+/* $Id: imapd.c,v 1.439 2003/08/22 16:31:42 rjs3 Exp $ */

 #include <config.h>

@@ -2389,6 +2389,7 @@
        }

        /* Read size from literal */
+       isnowait = 0;
        size = 0;
        for (p = arg.s + 1; *p && isdigit((int) *p); p++) {
            sawdigit++;
"

At this point, all I can do is hope that you can get MIT to upgrade the server,
or try applying the patch. It's true that this problem does seem sensitive to
versions of the client, and e-mail client, but the Cyrus guy told me flat out
there was nothing I could do on the client to get the server to flush its buffer.
I just wanted to comment that this bug has nothing to do with any particular
IMAP server. I use 2 different IMAP servers for my mail but the spin happens
when saving to the Local Sent folder not the imap folder.
perhaps what you meant to say is that there are different bugs involved
here...obviously, spinning when copying to an imap folder is a completely
different bug than spinning when copying to a local sent folder.
That is an interesting point. But I do not know how obvious it is that there are
two different bugs. Could someone who has seen the code involved confirm if the
bug which makes it spin on local folders is the same as for imap folders?
yes, I can utterly confirm that.
Just to state it again: POP3 is also affected, at least if not a local folder
but a network mounted one.

pi
I've noticed this today with Sent and Drafts on IMAP (Courier IMAP server),
Mozilla 1.6 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115) on
Fedora Core 1 when I've tried sending a message while the browser waas
displaying a cookie acceptance dialog.

The cookie acceptance dialog isn't certainly the only thing that can trigger
this bug, but at least it is easy to reproduce.

The scenario was:

1) Copying message to "Sent" failed after a timeout period
2) I've pressed "Save" button in order to at least save to "Drafts" folder (it
sometimes helps as a workaround for me when saving to "Sent" fails)
3) Saving to "Drafts" timed out too
4) I've switched to browser window only to discover a dialog asking whether to
accept a cookie from a site
5) After I've accepted the cookie, saving to "Drafts" of the same message
started working.

BTW, I want to signify that the cookie dialog isn't certainly the only thing
that can trigger this bug, but one that I've observed and might be interesting
for you.


the spin when a modal dialog is up is bug 74331 - that's a general problem, that
urls can't run when a modal dialog is up.
Closing and restarting Mozilla most of the time temporarily resolves the problem.
The problem occurs with Mozilla 1.7 on Windows 2000 still (build 20040616)

The OS field in this bug report should probably be changed to All.

An additional observation: when the problem occurs, even after cancelling the
copy action the folder "Sent" in local folders cannot be opened, trying to open
the folder just hangs.

After restarting the browser, the folder "Sent" was accessible again and Mozilla
asked if it should compress local folders.
Well, I had been seeing similar problems (although I thought my problems were
related to IMAP) since Mozilla 1.3, but I am currently using Mozilla 1.7 (and
previously ThunderBird 0.5) and haven't seen the problem at all. My IMAP server
and client PC (Windows 2000) haven't changed during this time.
OS: Linux → All
Hardware: PC → All
Product: MailNews → Core
*** Bug 250657 has been marked as a duplicate of this bug. ***
*** Bug 244631 has been marked as a duplicate of this bug. ***
*** Bug 271941 has been marked as a duplicate of this bug. ***
*** Bug 260540 has been marked as a duplicate of this bug. ***
Adding my comments from bug 250657 which got marked a dupe as my circumstances
seem completely different:

I experience this connecting to an exchange 5.5 SP3 server over IMAP, not using
SSL, with thunderbird 1.0rc on fedora core 3 (built from sources). Same problem
on official FC3 RPMS for 0.8, 0.9-1 and 0.9-2

I should add the following:
- it always does send, and copies it to sent successfully
- the first one hangs at 100%, the next (if there is still something open) keeps
trying to send in the dialog (though is as successful as the first)
- it causes the first mail I receive afterwards to be unopenable (it always
appears blank)
- several people have complained of the same problem as me at mozillazine:
http://forums.mozillazine.org/viewtopic.php?t=63477
- if I leave the window open, it eventually sends (possibly related to next)
- if I can convince tb to check the sent folder on IMAP, that seems to fix it
and the windows close.
I often have this problem when copying to folders "Sent" or "Drafts" on my LOCAL
folders.  I have seen the problem for years, and today became frustrated enough
to try and report it.  I found this bug, which seems close, but i want to stress
that my problem is with LOCAL folders.  My setup is thus:

 - 2 separate email accounts using IMAP for retrieval.
 - I send mail via SMTP to a postfix server on localhost.
 - Preferences for both accounts are to store sent,drafts,and templates in
appropriate folder in "Local Folders".

Given the above, I do not believe there should be _ANY_ IMAP interaction taking
place when I send mail.

So here is what happened just now, blow by blow.  It is typical of the usual
scenario.  I do not know how to replicate it exactly.  If I did, I would avoid
those steps when sending mail. 

The mailer was able to successfully send the mail via my localhost server, yet
it still failed when "copying" the mail to my sent folder.  Since the only
"copy" currently available is in memory, this basically means it was unable to
write to my local disk for some reason.

Yet it did not give an error message of any sort.  It just sat there forever
waiting for the "copy" (local write) operation to complete, saying "Copying
message to Sent folder".

<rant>
I have read comments above about there being bugs in specific versions of IMAP
servers, etc.  Whatever. I don't care.  The bug I am seeing is that thunderbird
is unable to write to a local folder from its own memory, and then sits there
forever without even giving an error message.  It seems to me that a very first
effort at a fix would be to create a timeout for the operation  (or better yet
just report a local write failure when it occurs)!
</rant>

Okay, so moving on.  After waiting several minutes, I finally decide to hit
cancel.  I then chose the "Save -> Draft" option.  It did not complain, but I
don't know if it was actually copied or not.  I then tried to close the window
and it informs me that the message was not sent ( it _was_ sent, just not
"copied"! ) and asks if I would like to save it in the Drafts folder.  I think
it should already be there, but I choose yes, just in case. It then goes into
the endless loop with the "Copying message to Drafts folder..." throbber dialog.

I am seeing this problem with both Mozilla Suite 1.7.3 and Thunderbird 0.9, both
from the latest Gentoo Linux builds.

fwiw.
Dan, we don't know how to reproduce the problem. Otherwise, we'd fix it. We
believe that we do give an error if we're unable to write to the sent folder (in
other words, it's not a matter of looking for the code that does that and
checking for errors).
David,

Anything those of us experiencing it consistently can provide to help you out? 

It seems to me there are several different issues that all have the same
symptom, so I feel for you in how hard it must be to reproduce :)

As it happens, I'm getting it a whole lot less at the moment, though nothing is
theoretically changed (I did upgrade to 1.0, then back down to 0.9 until my
favourite extensions are compatible). I have seen it happen since though.

Thanks.
(In reply to comment #68)
> Dan, we don't know how to reproduce the problem. Otherwise, we'd fix it. We
> believe that we do give an error if we're unable to write to the sent folder (in
> other words, it's not a matter of looking for the code that does that and
> checking for errors).

I am consistently getting this problem with Thunderbird 1.0 (I've had this
problem since at least 0.8). I have two IMAP servers, and I only have the
problem with one of the two mail servers. I never use the Local Folders, so I
can't help you there. I've bypassed the problem by keeping two "Sent" folders on
one server that is working, and never writing new mail to the one server that
isn't working.

I have no idea where to begin diagnosing this problem, but I would be more than
happy to submit logs if I knew how to generate them, or try some troubleshooting
if I knew what to try. Is there any tests that someone would like me to try in
order to narrow down what is causing the problem?

One other note, in responce to Dan, I've seen an error message which says
(roughly) "The message was sent, but it wasn't copied to the Sent folder".
However, the message usually takes several minutes before it appears. I'm not
talking 60 seconds, I'm talking walk away, do something else, and come back to
find the error message. Have you tried this?
> One other note, in responce to Dan, I've seen an error message which says
> (roughly) "The message was sent, but it wasn't copied to the Sent folder".
> However, the message usually takes several minutes before it appears. I'm not
> talking 60 seconds, I'm talking walk away, do something else, and come back to
> find the error message. Have you tried this?

Yes.  I usually (always?) see this notice when the bug occurs.  It probably
happened today as well, but I was writing the description from memory.  Oh, and
it doesn't usually take very long either.

If it helps, the IMAP server I am using when I usually see this is at hostname
mail.libby.com. ( I don't know what software they use specifically. )

David, thanks for the reply. Without looking at the code I would guess that one
of two things is happening during the copy to sent folder action:

 1) it for some reason tries to query the IMAP server for something.  tbird
never receives a reply, or there is some problem with the communication.  ( IF
it is querying the IMAP server for any reason in this case, that seems like a
bug to me. )

 2) Some sort of locking/threading issue.  I assume that all writes to the local
mail folders are locked via some mechanism.  How/when do they become unlocked? 
Since subsequent write operations also fail until I restart the program, this
seems a likely culprit.

Okay, so having already written the above, I just ran a packet sniffer
(ethereal) for a bit.  My methodology was:

1) restarted thunderbird (to clear the stuck state).
2) unchecked "check mail every X minutes option for both accounts.
3) began capturing all TCP port 143 and 993 packets. (imap, imaps)
4) sent a message to an unrelated account
5) waited for a few more minutes.

observations:

a) the copy to sent folder operation succeeded normally.
b) no imap activity was present during the send/copy operations. (yay!)
c) there are 11 packets sent between the libby.com server and my machine every
minute or so.  I'm no IMAP expert, but they appear to be some sort of keepalive
mechanism (IDLE, NOOP, DONE, Uid fetch).  This is occurring on port 143.
d) there were not any packets observed during the same period between my machine
and the other IMAP server, which uses imaps on 993.
e) the packets in observation c are probably normal, but I wonder then why there
were no packets sent to/from the other server...?

I can post the packet log if you think it might be useful.

Finally, given the long-standing nature of this bug, and its severity -- saving
sent mail is pretty important functionality for a mail client -- I wonder if you
might consider some sort of workaround:  eg, detect if the local save operation
has been running for more than 15 seconds, and if so offer to save it as a local
file using a routine that is more likely to succeed than whatever "copy between
folders" API is being used now.  And/or maybe do some extra checking for stale
locks left behind by someone naughty...
I don't believe this is a problem just with IMAP - although I must say, once i used purely POP email I 
experience this problem much less. But occosionally now I get the same problem:
1. Send the email
2. It hangs on the message "copying to sent folder" (note a purely local folder), it will just hang forever 
trying to copy to the sent folder...
logfile (protocol IMAP) for sending mail that should be stored in folder sent.
Comment on attachment 175272 [details]
Logfile for IMAP access

I can confirm problems with saving mail in the folder "Sent" as well as in the
folder "Drafts" - but it only happens on my WindowsXP (TB 1.0) with IMAP and
only with IMAP accounts on my intranet mailserver (Cyrus). And it happens
everytime when trying to save mails in "Sent" or "Drafts". 

Moving (or copying) mails between folders within that IMAP seems to work. But
moving (or copying) mails from other account folders to those IMAP folders
doesn't work - the status line shows TB working without ending but actually it
doesn't copy (same attitude as saving sent mail but without the dialoque box).

On linux client side (TB 0.85) everything works fine with those Cyrus IMAP
accounts (also with Kmail).

prefs.js:
user_pref("mail.identity.id10.fcc_folder", "imap://frank@tso1/Sent");
user_pref("mail.identity.id10.fcc_folder_picker_mode", "0"); 

Created an attachment with a TB logfile <a
href="https://bugzilla.mozilla.org/attachment.cgi?id=175272">ID 175272</a>. It
may look like the folder location isn't correct (not realy familiar with IMAP
protocol).
3720[2746278]: 2fbbdf0:tso1:A:CreateNewLineFromSocket: 10 OK Completed (0.000
secs 5 calls)

0[348d8]: 2fed4d8:tso1:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
0[348d8]: queuing url:imap://frank@tso1:143/listfolder>^Sent
0[348d8]: considering playing queued url:imap://frank@tso1:143/listfolder>^Sent
0[348d8]: creating protocol instance to play queued
url:imap://frank@tso1:143/listfolder>^Sent
0[348d8]: failed creating protocol instance to play queued
url:imap://frank@tso1:143/listfolder>^Sent
0[348d8]: queuing url:imap://frank@tso1:143/listfolder>^Templates
0[348d8]: considering playing queued url:imap://frank@tso1:143/listfolder>^Sent
0[348d8]: creating protocol instance to play queued
url:imap://frank@tso1:143/listfolder>^Sent
0[348d8]: failed creating protocol instance to play queued
url:imap://frank@tso1:143/listfolder>^Sent
3720[2746278]: 2fbbdf0:tso1:A:SendData: 11 append "INBOX.Sent" (\Seen) {700+}

On the server side the IMAP folders of the accounts look like:
localhost> lm *frank*
user.frank (\HasChildren)	    user.frank.Sent (\HasNoChildren)
user.frank.Drafts (\HasNoChildren)  user.frank.Trash (\HasNoChildren)
localhost> lam user.fra*
user.frank:
  frank lrswipcda
user.frank.Drafts:
  frank lrswipcda
user.frank.Sent:
  frank lrswipcda
user.frank.Trash:
  frank lrswipcda 

On the server side neither /var/log/messages nor /var/log/mail show anything
abnormal concerning that connection.

No workaround found that works so far. I started implementing my mailserver in
the intranet so I can store and backup my mails centralized. I'm afraid I will
have to try Pegasus Mail again (used it before but so far without IMAP).
this looks like a server bug - we issue the append and promise to send 700 bytes
of data:

append "INBOX.Sent" (\Seen) {700+}

...

</html>



3720[2746278]: 2fbbdf0:tso1:A:SendData: 

3724[2745fe8]: ImapThreadMainLoop entering [this=2fed4d8]

and the server never responds with OK. The Cyrus server has had this problem off
and on, it looks like.  You could verify that we are actually sending the number
of bytes promised, but I've gone through that code a number of times.

A workaround is to bonk the offline button a couple times, which will cause us
to send a logout to the imap server, which it will interpret as more data for
the message, and cause it to unblock the connection. Or, in trunk builds, we
have a timeout, so we'll eventually time out when the server stops responding.
(In reply to comment #75)
> this looks like a server bug - we issue the append and promise to send 700 bytes
[...]
> A workaround is to bonk the offline button a couple times, which will cause us
> to send a logout to the imap server, which it will interpret as more data for
> the message, and cause it to unblock the connection. Or, in trunk builds, we
> have a timeout, so we'll eventually time out when the server stops responding.

Bonking on the offline button causes TB to crash (I guess the correct
translation is for the message in the task manager is "no response"). Having a
timeout would sincerly be appreciated :-) especially because all that happenes
_everytime_ trying to store a message in any IMAP folder. Even simply clicking
on a folder other than the inbox leads to the message "opening folder..." in the
status line (doesn't disappear) and sometimes this also leads to a timeout. 

I suspect that this almost annoying behavior relates to Thunderbird in Windows
only? 

- Windows Pegasus Mail works fine with Cyrus IMAP (guess David Harris uses other
routines communicating with IMAP)
- Linux KMail and Thunderbird 0.8 / 1.0 also work fine with Cyrus IMAP

For me TB is not a solution for accessing my Cyrus IMAP server. I tend to use
Pegasus Mail because I hesitate to incorporate into another IMAP server. Maybe
I'll give courier IMAP a try - I just don't now by now...
This is happening today sending messages. If you try and close the message and
save  it to the drafts folder the smae happens. I am running Build : 20041206 on
XP Pro.
I have irritated users who often have this exact same problem with build
20050317 on Windows XP Pro and build 20050116 on Linux. SSL is enabled. The
server is Courier IMAP.
Recent fixes for bug 287658 (as of 28-Mar) and bug 123063 (as of 30-Apr) may 
have addressed issues people are seeing for IMAP; please try a current nightly 
build of Mozilla or TB, whichever you're using -- be sure the build is dated 
May 1st or later before bothering to download, as the nightlies on 
ftp.mozilla.org are not getting regular updates.

There are plenty of references to POP and Local 'Sent' folders in this bug; 
these problems will not be affected by the recent patches.
Using Thunderbird 1.02 on Mac OS X 10.3, there is not a hang when sending a 
message, but rather an immediate error that the message was sent but there was 
an error copying to the Sent folder.  In the error dialog, there is a prompt to 
Retry the copy to Sent, but the error just reappears immediately when hitting 
OK.  Only hitting Cancel will get rid of the error.  Sometimes, there is an 
error copying to the Sent folder, and other times it works without a hitch.  
The Sent folder is an IMAP folder on the mail server. Thanks.
I just encountered the problem again using build 20050502 on Windows XP (SP2). 
I'm using non-SSL IMAP.

It looks like there has been some progress in how Thunderbird handles or
recovers from this problem.  After about an hour of "spinning" I tried to close
the compose window and I was asked if I wanted to continue waiting or cancel the
send.  When I hit cancel, I was immediately prompted with an error about copying
the message to the "Sent" folder and do I want to retry?  I told it to retry but
was prompted with the "retry" question two additional times (immediately after
clicking "OK" to the retry question) -- the last one seemed to stick.  

I wasn't able to view the "Sent" folder until I hit the stop button in the
toolbar.  When I finally got the "Sent" folder list I noticed three copies of
the email I was trying to send.
(In reply to comment #79)
> please try a current nightly 
> build of Mozilla or TB,
With the 20050503 nightly things have become a lot better, though not perfect.
Thunderbird still stalls sometimes when you copy a message to a folder on the
IMAP server, but it now recovers without shutdown (the cancel button now works
as expected). An error is reported, but the message is copied to and becomes
visible in the target folder.
I hope the bugfixes mentioned in comment #79 make it into an official release
soon (several extensions don't work with the nightly).
It is hard to believe that all these servers are broken, but our code that
appends a message to an imap folder is not complicated - it spools everything to
a temp file, gets the size of the temp file, tells the server we're going to
send it that exact number of bytes, and then we send it that number of bytes,
followed by a CRLF, and then wait for a response from the server. No one has
been able to show me an imap protocol log where we promise to send XX bytes but
only send XX-1 bytes, but I've seen lots of logs where we promise to send XX
bytes, send XX bytes, and never get a response from the server. If anyone can
show me a log where we're not sending the right number of bytes, I can look into
it. I do not know why this doesn't cause other clients problems but perhaps they
ignore the response from the APPEND command, if any...



(In reply to comment #83)
> It is hard to believe that all these servers are broken, but our code that
> appends a message to an imap folder is not complicated - it spools 
everything to
> a temp file, gets the size of the temp file, tells the server we're going to
> send it that exact number of bytes, and then we send it that number of bytes,
> followed by a CRLF, and then wait for a response from the server. No one has
> been able to show me an imap protocol log where we promise to send XX bytes 
but
> only send XX-1 bytes, but I've seen lots of logs where we promise to send XX
> bytes, send XX bytes, and never get a response from the server. If anyone can
> show me a log where we're not sending the right number of bytes, I can look 
into
> it. I do not know why this doesn't cause other clients problems but perhaps 
they
> ignore the response from the APPEND command, if any...

Dear David,
please read the initial post in this bug page -
"The bug seems to be network-unrelated, as the problem has occured with IMAP,
POP3 and Local folders."

I confirm, this bug still occures in the Thunderbird when account is
configured to save copies to the _LOCAL FOLDERS_! You not need "wrong IMAP log"
from "evil" IMAP server to analyze this bug - the problem somewhere else!

Andrey, several things:

there have been five or six bugs at least that produced this same symptom. I
know they all look the same to you, but they're very different. So the initial
post from 2 years ago, not so relevant today :-)

There have also been several very different fixes that went into the code at
different times. So what build are you using that has this problem? Since this
is your first comment in this bug, I don't really know what your usage scenario is.
> different times. So what build are you using that has this problem? Since 
this
> is your first comment in this bug, I don't really know what your usage 
scenario is.

My initial report on this bug is in the 
https://bugzilla.mozilla.org/show_bug.cgi?id=260540 (about year ago)
for TB 0.8. It was marked as duplicate of this bug.
And it still relevant for the TB 1.0 :-(
I will check this with the 2005-05-11-08-trunk, now downloading...
> I will check this with the 2005-05-11-08-trunk, now downloading...

Oops, this build didn't works at all. Returning back to 1.0.2.
the work I described has mostly been since 1.0, so you'd have to use a trunk
build, or wait until 1.1 comes out.
I am having this problem too. I am using Thunderbird version 1.0.2 (20050317) on
a Windows XP Professional w. SP2 - System. My Sent-folder is remote on the
IMAP-Server.

This problem only happens from time to time, so I don't know how to reproduce it. 

But there are a few differences: The progressbar of the copying process shows
the correct progress, so if it is at 100%, the message IS available in the
sent-folder. But the message above doesn't always show "copying message to sent
folder", but more often "sending authentication information...". So it seems
that this problem is not produced by the copying itself, but by the status message!
This bug's been biting me for a while now. I may have gotten a step closer to
isolating it. Let's see if any of this helps... Thunderbird 1.02, Windows XP
Home with recent updates, **** wireless network connection, secure IMAP (TLS)
into port 993.

This isn't exactly the same set of symptoms as reported before, but the behavior
is similar.

Symptoms: (1) Control-click to select several messages to delete. Hit the
"delete" key. Nothing happens. Go away for a couple hours, still nothing. (2)
Click into the inbox for a different IMAP folder, log in there. Then click back.
Hit delete, still nada. (3) Bop the "work offline" button, no download. Go back
online. Click "get new messages". System reports no new messages. Control-click
messages to delete them, nothing happens.

Thunderbird's log shows stuff that looks like this:

------------
3620[2d595c0]: 2d06c50:k2.moriarti.org:S-INBOX:SendData: 5 noop^M
3620[2d595c0]: ReadNextLine [stream=3c6be58 nb=22 needmore=0]
3620[2d595c0]: 2d06c50:k2.moriarti.org:S-INBOX:CreateNewLineFromSocket: 5 OK NOO
P completed.^M
3620[2d595c0]: 2d06c50:k2.moriarti.org:S-INBOX:SendData: 6 UID fetch 159350:* (F
LAGS)^M
3620[2d595c0]: ReadNextLine [stream=3c6be58 nb=35 needmore=0]
3620[2d595c0]: 2d06c50:k2.moriarti.org:S-INBOX:CreateNewLineFromSocket: * 871 FE
TCH (UID 159349 FLAGS ())^M
3620[2d595c0]: ReadNextLine [stream=3c6be58 nb=23 needmore=0]
3620[2d595c0]: 2d06c50:k2.moriarti.org:S-INBOX:CreateNewLineFromSocket: 6 OK Fet
ch completed.^M
0[348c8]: considering playing queued url:imap://jeff@k2.moriarti.org:993/listfol
der>/archive/backup/msg.-DMO
0[348c8]: creating protocol instance to play queued url:imap://jeff@k2.moriarti.
org:993/listfolder>/archive/backup/msg.-DMO
0[348c8]: failed creating protocol instance to play queued url:imap://jeff@k2.mo
riarti.org:993/listfolder>/archive/backup/msg.-DMO
3620[2d595c0]: 2d06c50:k2.moriarti.org:S-INBOX:SendData: 7 IDLE^M
3620[2d595c0]: ReadNextLine [stream=3c6be58 nb=10 needmore=0]
3620[2d595c0]: 2d06c50:k2.moriarti.org:S-INBOX:CreateNewLineFromSocket: + idling
------------

(The whole log is rather long. Let me know if you really want it...)

The "failed creating protocol instance" messages seem fairly common. I haven't
dug into the sources to see what they mean, yet.

Tried to get an ethereal capture of the session, but no dice: I could get only
half the conversation for some reason. (I'm not sure how helpful it would've
been, since it was in TLS anyway, except to show the number of TCP retransmits
that happen over this connection.) I know the network adaptor's alive, though,
because I was able to get to this web page.

Final troubleshooting step: halt thunderbird and restart it. I verified with
task manager that no processes are hanging around. On restart, all is happy and
deleting works as expected.
Jeff, can you try a tbird 1.1a build? There have been several fixes in this
area, none of which are in 1.02
I've installed 20050531. I'll let you know how it works.
I tried 1.1a1.  Trouble details (and working workaround details) in 2
back-to-back posts here:
http://forums.mozillazine.org/viewtopic.php?p=1536680#1536680  HTH. Thanks, David.
those errors look like imap server errors, which we are reporting to you - in
particular, it seems like you have disk space problems on your server, or a
buggy server.
  Ok, so 1.1a1 seems to be better WRT to this bug: I didn't see this bug for
around a week.  However, 1.1a1 truly an alpha - it crashed a 3 times, whereas
1.0.4 was stable for weeks.
  I switched back to 1.0.2, and this bug is recurring, specifically the cursor
spins forever when copying the message to Sent Items, and when cancelled, the To
and Subject fields remain greyed out.  The IMAP server errors have not recurred
(yet).
  I haven't seen the server errors in the screen shots I posted since I posted them!

Possibly relevant: when I click on "Manage Identities..." in Account Settings,
nothing happens.  

  I guess I'll stick with 1.1a or newer, and help make it more stable/confirm
that this bug [really is|stays] fixed.
Attached file Extract of Log — 
I just ran into this bug on Thunderbird 1.0+ 20050531. (It's been difficult to
reproduce, since the wireless connection's been worse than normal lately.)
Here's the log file, with a lot of repetitive stuff (and the contents of the
e-mail message) deleted.
Additional info: /var/log/maillog on the server shows multiple incoming
connections to dovecot:

Jun 24 21:01:14 k2 imap-login: Login: jeff [::ffff:68.6.205.122]
Jun 24 21:11:20 k2 imap-login: Login: jeff [::ffff:68.6.205.122]
Jun 24 21:21:20 k2 imap-login: Login: jeff [::ffff:68.6.205.122]
Jun 24 21:31:23 k2 imap-login: Login: jeff [::ffff:68.6.205.122]

Nothing exciting in /var/log/messages. 
Hi

I am experiencing the same problem. First using Sent-folder on Imap (cyrus on
Linux). Then, I configured the Sent-folder to be under Local-Folers and the
problem remains, although less often.

Thunderbird Version 1.0 (20041206), Windows 2000

Some observations:
--  The problem never occured sending the first mail after starting up Thunderbird.
--  The problem occurs more often, if I use unreliable links (strange, as the
Sent-Folder is local).
--  After stop & restart of Thunderbird the problem goes away for a few sent
mails and then often re-occurs.
--  The problem seems to occur earlier, if I also move message to other folders.
--  Sometimes, the hanging "copy to sent folder" operation recovers if I access
(select) the Sent-folder. If so, immediatly after the Sent-folder is selected,
the message or messages are stored.
--  Note: My Sent-folder is usually empty.
--  Note: I often have multiple message in sending or Sent-folder mode, due to
slow, bad Internet link and long elapse times to even send small messages.
(In reply to comment #98)
> I am experiencing the same problem. First using Sent-folder on Imap (cyrus on
> Linux). Then, I configured the Sent-folder to be under Local-Folers and the
> problem remains, although less often.
> 
> Thunderbird Version 1.0 (20041206), Windows 2000

mozilla@tracy.bot.ch: That build is pretty old (about 7 months old by now).
Please try a more recent build:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
*** Bug 290368 has been marked as a duplicate of this bug. ***
I can confirm seeing this behavior somewhat regularly in Thunderbird 1.0.6
(20050716) on Windows 2000, using IMAP folders running against a dovecot-0.99.14
IMAP server, with Maildir format folders.

Tried following the advice in this attachment to the current bug, to no avail -
the problem continues to occur with either setting for the "Sent" folder.
https://bugzilla.mozilla.org/attachment.cgi?id=137753

I know that our NAT router (which sits between my machine running Thunderbird
and the IMAP server) regularly forgets about long lived TCP connections. 
Perhaps this is a factor. 
some things that were broken in 1.06 have been fixed in the trunk builds,
including 1.1a2
In case this is useful in locating the problem, here's my latest experience with
the hanging problem.

I sent my last mail using TB1.0.6 on 5th August.  W2K, corporate IMAP email
system.  I save mail to local sent mail folder, not IMAP server.  I have several
IMAP servers and several SMTP servers.

On returning from holiday today and firing up my maching, I had approx 380
mails.  Many of these are from mailing lists and are filtered to local folders
using message filters.  Some was spam.

During the spam and filter processing I did some operations to read existing mail.

When I tried to send my first mail since 5th August, it hung trying to copy to
the sent folder.  I had this sometime many months ago on 1.0.2 and read
something about deleting panacea.dat, so I did that and deleted the .msf file
with no luck.  I compacted folders and then found the problem was extended to
the drafts folder too.

There are two local folders, however, that I cannot view.  They have new mail
because they are bold, but the number of new mails is not shown.  They are
folders into which filtered mail is downloaded to.  

When I click on them I get an alert stating "Unable to open the folder X because
it is in use by some other operation.  Please wait for that operation to finish
and then select the folder again."  I have quit the TB process.  I recall that
this similar problem occurred the last time I got the hanging problem, but just
can't remember how I got round it...

If I find out the solution I'll post.



I noticed another factor that seems to influence the hang, although not
reproducibly.

When starting to respond to a mail on an IMAP server, then deleting the original
mail while the response is still open, then sending the response does send the
mail but hangs when trying to copy the mail to the Sent folder (which happens to
be a local folder).

(In reply to comment #103)

In my case, the problem was caused by failed filtering.  The two folders that
were causing the problems were locked by the TB process when it was running. 
(In DOS, I tried to move the file to some other location and Windows would not
let it), so I did the following and now it will save a copy to the Sent folder
when I send mail again.

1. Quit TB
2. Moved the file associated with the mail folder (e.g. c:\Documents and
Settings\User\Application Data\Profiles\Main\Mail\Local Folders\XXX to a temp
location and restarted TB.  On restart TB said that the folders no longer
existed and that it would disable the associated filters.

At this point all the mails affected by the filters reappeared back in my IMAP
inbox (they had not been visible to that point).

3. Quit TB
4. Move the files from (2) above back to their correct location.
5. Restart TB and click on the folders. It builds a summary file and I can now
see the messages.  There are duplicates of filtered messages and this appears to
be the crux of the problem.  Each time I restart TB, it tries to make the
filtering and something stops it.
6. Delete the partially filtered mails (the originals still exist in the IMAP
inbox, even the ones that have been filtered)
7. I then marked groups of the mails that should be filtered and moved them
manually to the local folder.  This did NOT always work and the manual move
FAILED.  I had to quit TB and start again from 5 above and in the case where a
group had failed, moved the mails individually.  Eventually I got all mails from
IMAP inbox moved to their respective folders.
8. Sent a new mail and it gets saved OK to the sent folder.

It therefore seems that something causes the filtering to hang.  As this symptom
occurs also when moving more than one mail at a time, but not when doing it
individually it seems to be related to mass move of multiple items.

I recall the first time it occurred I found two mails from one individual that
seemed to cause the problem.  What if these messages had the same message ID? 
Could it be that the traversal of the message set to be moved hangs if the
message ID is the same?  I did not track down the exact message this time, but
for each folder there was one group that did not move as a group.

Hope this helps track things down.

Again, to anyone running 1.06 and having this problem, please try a trunk build,
for example, 1.1a2 -
ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/1.1a2/

I've fixed several problems that caused these symptoms, in the 1.1a2 build.
I'm now using 1.1a2, and the impact of the problem is less, although I'm not
willing to say that the problem is solved.

In Thunderbird 1.1a2, I still sometimes get a hang on the message "Copying
message to Sent folder".  The difference is that if I hit Cancel, it drops me
back in the compose window, with an error alert "There was an error copying the
message to Sent folder. Retry?".  If I hit Retry at that point the Save
completes correctly.  

So, I can at least reliably keep a copy of every outgoing message.  It just
means that I sometimes have to "Cancel" before "Retry".

I imagine that this approach won't work for most users, who would have no idea
that hitting Cancel will put them back in the composition window with the option
to try again, as opposed to cancel sending the message entirely, or cancel
saving a copy of the message.
(In reply to comment #107)
> In Thunderbird 1.1a2, I still sometimes get a hang on the message "Copying
> message to Sent folder". 
Oh, it's good news for me because you can re-produce this bug on 1.1a2 :-) 
Could you get IMAP protocol log?
Let developers to know what situation still causes "spin when copying message to
Sent folder", as soon as possible, please. 

> So, I can at least reliably keep a copy of every outgoing message.  It just
> means that I sometimes have to "Cancel" before "Retry".
It's better news!
Thanks to developers for fixing problems and implementing enhancements. 

>I imagine that this approach won't work for most users
I agree with you, but I think you'd better to open new bug for enhancement,
because this bug is for analyzing & solving of "spin" problem.
See Bug 277071 for this kind of request, which had become "obsolete" by another
enhancement.
(In reply to comment #108)
> (In reply to comment #107)

> Oh, it's good news for me because you can re-produce this bug on 1.1a2 :-) 

That depends on what you mean by re-produce.  It took more than a week of using
1.1a2 to determine with confidence what the new behaviour is.  The bug shows up
no more than once per day or so.

> Could you get IMAP protocol log?

Perhaps.  I would need to use a logging tool that I can leave running in the
background for many hours.  Any suggestions on how to do this?

> Let developers to know what situation still causes "spin when copying message
> to Sent folder", as soon as possible, please. 

The occurrence of the problem is much the same as in version 1.0.6 ... the
problem shows up intermittently when sending a message.  When the problem shows
up it results in the Send dialog stalling indefinitely long on the message
"Saving message to sent folder".  Subjectively it seems to occur more often
after composing a long message, and might have something to do with dropped TCP
connections, as our NAT router seems to drop long-lived connections.
 
> ... but I think you'd better to open new bug for enhancement,
> because this bug is for analyzing & solving of "spin" problem.

Humbly, I must disagree.  It appears to me that the impact of this bug has been
reduced, but the root cause remains in 1.1a2.  I say that because the
problematic behaviour of the send window occasionally stalling for an
arbitrarily long time is exactly the same as in 1.0.6. 
Oliver, you can generate an imap protocol log by following these instructions,
substituting IMAP for "protocol"

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

In 1.1a2, tcp connections should timeout after 60 seconds of inactivity, as
controlled by the pref "mailnews.tcptimeout" - so if it is the case that your
NAT router is dropping the connection, in theory we should timeout after 60
seconds. You can reduce that timeout if you want. You can also change the length
of time we'll cache imap connections by setting a per server pref
mail.server.serverxx.timeout, where serverxx is your imap server, and the value
is the integer number of minutes we should assume idle connections stay alive
for. The default is 29 minutes, because that's what the IMAP RFC specifies. If
you know your NAT router drops idle connections after fewer minutes, then you
should definitely try changing that pref.
Note: As reported earlier, I believe the issue is _not_ IMAP, but rather related
to locking of folders. It took me 10 minutes to reproduce the problem with
version 1.6a1 (20050830). See also
https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c98

For my IMAP account, I configured the sent folder under Local Fodlers, and the
problem persists and manifests itself exactly the same way.

Observation:
The problem usually occurs over low-bandwith connection (ie. GPRS) or dialup
connection. Also, the problem usually occurs when doing some clean-up of the
Send folder while a new mail is being sent. The problem usually happens on low
bandwith connection, because while a mail is being sent out, I use the time
waiting for the mail being sent to do the clean-up of my sent folder. The
problem can easily be reproduced using broadband connections.


Configuration:
-- IMAP-Account on an IMAP server accessed over the Internet (broadband connection).
--  Sent Folder configured on Local Folders


Reproduce:
--  Prepare a Sent folder (on Local Folder or IMAP server) with some "large"
emails. The size is only important to be able to perform concurrent operations
on the Sent folder which take some time, ie. a couple of seconds.
--  Create a new "large" email, e.g. with an attachment. 
--  Send the mail.
--  As soon as it takes some 15 to 20 seconds to complete the sending (SMTP),
start copying several individual emails from the Sent folder to some other
folder: Select an email in the Sent Folder, CTRL-drag it to some other folder;
repeat before the copy operation completes
--  The SMTP operation completes; the email is being copied to the Sent Folder;
error occurs, "Copy to Sent Folder failed".

Note: At least one copy operation must be still ongoing when the SMTP operation
completes and the email is copied to the Sent folder.

Note: I created an IMAP log and will provide it upon request and after removing
personal infromation.


(In reply to comment #109)
> It took more than a week of using 1.1a2 to determine with confidence
> what the new behaviour is.
> The bug shows up no more than once per day or so.

Your case is relieved by "Timeout detection", then "No response from IMAP
server" seems to be involved in your case.
This "No responce from IMAP server" is possibly caused by mismatch of "cached
connection count" setting of Thunderbird(default=5) and connection "count limit
from a single IP address" setting of IMAP server(default=5 if Courier-IMAP).
(See Comment #23 and Bug 196732 comment #63)

Oliver Crow, can you test with larger value of "cached connection count"?
And, if your problem was re-producable freequently than before, watch effect of
smaller value of "cached connection count".

  
Correction of my comment(sorry for spam)
 default=5 if Courier-IMAP ==> default=4 if Courier-IMAP

(In reply to comment #112)
>  
> Oliver Crow, can you test with larger value of "cached connection count"?
> And, if your problem was re-producable freequently than before, watch effect of
> smaller value of "cached connection count".


I've tested with Account Settings > Server Settings > Advanced > 'Maximum number
of connections to cache' set to 15, in place of the default of 5.  This does not
make any appreciable difference ... the problem with hanging when saving to the
Sent folder continues to occur with roughly the same frequency as before. 

Just for reference, I'm using Dovecot IMAP server, not Courier.  It does not
appear from the Dovecot documentation that there is a setting for the maximum
number of connections per IP address in Dovecot ... it allocates connections as
required.

So, I think we can rule out mismatched connection limits between Thunderbird and
the IMAP server as the cause in this case.





IMAP Log

-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:ProcessCurrentURL: entering
-1251759184[95420d0]:
9585378:imap.server.used:S-INBOX:ProcessCurrentURL:imap://user@imap.server.used:143/ensureExists%3E%5ESent:
 = currentUrl
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:SendData: 17 list "" "Sent"
-1251759184[95420d0]: ReadNextLine [stream=94b9e88 nb=38 needmore=0]
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:CreateNewLineFromSocket:
17 OK Completed (0.000 secs 1 calls)
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:SendData: 18 create "Sent"
-1251759184[95420d0]: ReadNextLine [stream=94b9e88 nb=17 needmore=0]
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:CreateNewLineFromSocket:
18 OK Completed
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:SendData: 19 subscribe "Sent"
-1251759184[95420d0]: ReadNextLine [stream=94b9e88 nb=17 needmore=0]
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:CreateNewLineFromSocket:
19 OK Completed
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:SendData: 20 list "" "Sent"
-1251759184[95420d0]: ReadNextLine [stream=94b9e88 nb=36 needmore=0]
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:CreateNewLineFromSocket:
* LIST (\HasNoChildren) "." "Sent"
-1251759184[95420d0]: ReadNextLine [stream=94b9e88 nb=38 needmore=0]
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:CreateNewLineFromSocket:
20 OK Completed (0.000 secs 2 calls)
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:SendData: 21 IDLE
-1251759184[95420d0]: ReadNextLine [stream=94b9e88 nb=10 needmore=0]
-1251759184[95420d0]: 9585378:imap.server.used:S-INBOX:CreateNewLineFromSocket:
+ idling

Running 1.5 Beta 20050908

Steps to recreate issue

1. Use a server without a Sent folder
2. Send an email 
3. Hangs with Copying message to Sent folder

The email will be sent and a Sent folder will be created on the IMAP server but
you have to press cancel and close the window to proceed.

After this initial email everything will work fine.
(In reply to comment #110)
> 
> In 1.1a2, tcp connections should timeout after 60 seconds of inactivity, as
> controlled by the pref "mailnews.tcptimeout" - so if it is the case that your
> NAT router is dropping the connection, in theory we should timeout after 60
> seconds. You can reduce that timeout if you want. 

I followed your advice, and reduced the mailnews.tcptimeout from 60 seconds to
10 seconds (under Tools > Options > Advanced > General > Config Editor), with
the result that when a sending mail connection hangs, the server times out and
asks for a retry after 10 seconds, instead of 60 seconds.

It seems then, that when sending mail the server is attempting to reuse an
existing connection, and that if for some reason that connection has been
dropped, the server has to wait for the timeout before it can know to retry.
This supports the idea that the root cause is that the connection is being
silently dropped by the network (in my case a NAT router with a short timeout on
the NAT cache). Mozilla never receives notification that the socket is no longer
viable, so it waits for the timeout. 

Is there some way that Mozilla could avoid this case?  To an end user, it's not
clear that the problem is in the TCP layer; I just see an application that hangs
sometimes.  Could the app open a new TCP connection to the IMAP server when
sending mail?  Also, why does the app hang when saving a sent mail message, but
never (in my experience) when retrieving mail from IMAP?

I'm having the same problems. Using :

- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729
- bincImap 1.2.5 SSL mode on RH 7.3, kernel 2.4.21

How's the status of this bug?
the status is that there are fixes for a lot of instances of this bug, none of them are checked into the 1.7.x branch - many are in tb 1.5 and seamonkey 1.0a
For me, the following simple change provided a solution:
Instead of trying to store the copy of the message in the default 'Sent' folder (which actually did not exist on the server), I chose from 'Other' the 'SentMail' -folder, which does exist on the server.
So the problem actually was that there were no such folder as 'Sent'.

Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
(In reply to comment #118)
> the status is that there are fixes for a lot of instances of this bug, none of
> them are checked into the 1.7.x branch - many are in tb 1.5 and seamonkey 1.0a
> 

Is there any chance that this will be included in mozilla 1.7.x? A lot of our clients use this client and this is really anoying :( Thanks!
For whatever it's worth I see this problem regularly on Mac OS X 10.4.3 with Thunderbird 1.5 (20051025). It's gotten a lot worse in the last couple of days. Normally I can send two or three emssages without trouble, and then the next ones I send all hang while trying to copy the message to the local Sent folder. 
There seems to be some debate about whether this has anything to do with IMAP or not. I'm still exploring this but it appears to me that this bug activates when some other move is hung up moving messages to the an IMAP folder. For example, if messages are being deleted or filtered in to my IMAP Junk folder, and that's taking a long time, then I'm very likely to get see this error when sending a message a consequently copying a message to my Local Sent folder. If nothing else is moving anytrhing it IMAP, then I tend not to see this error message.

Is that possible? Could this be a result of a different improperly closed or dropped IMAP connection? 

If so, would it be possible to restrcuture the code so it doesn;t wait for operations on other folders to complete before copying the message to the Local Sent folder?

I could be completely off base here. I really don't know how the code is structured. But I do see a fairly strong correlation between deleting and/or junking mail and having this problem sending messages.


I second your observations and conclusions. I made a statement, that the problem might not be related to IMAP, which is a bold statement and most likely wrong (see Bug 206408#c111). The problem seems to be related to IMAP in general, but is not specific to the Sent residing on the IMAP server.
I've been following this bug for quite some time as I've had a lot of problems with it also.  After playing around with different things, I've found that if I set the "Maximum number of server connections to cache" to 1, I no longer have this problem.  I'm running IMAP with sent mail being saved on the server.  This is the only value that seems to workaround this problem.  Even going to 2 cause problems.  I was running V1.5RC1 with this and just updated to 1.6a1.  I will be trying to up this value to see if it comes back.
I've been having these problems with my IMAP Sent folder as well, using Thunderbird 1.0.7 on SUSE Linux. Setting "Max. number of server connections to cache" to 1 has also solved it for me.
I can reproduce "very often" this problem but only with an external IMAP server (outside of my local network). With an IMAP server in my local network, absolutly no problems.
Yes, this is also true in my case. I use two IMAP accounts next to each other in Thunderbird, one on the local network and one "external". Only the last one sometimes caused the problem when copying the sent message to its archive folder (I use the option to place the copy in a custom folder on this account instead of the standard "Sent").
I am an administrator for the University of Wisconsin - Madison email system.  We're running Sun iPlanet Messaging Server 5.2.  We have received many complaints from users concerning this problem - copying to Sent IMAP folder spins.  It's existed for us since the first version I installed - 0.5 I think.  I won't bother explaining the problem since previous posts have explained it adaquately.  I will attempt some of the workarounds and report back if I am successful.
I think I've found a way to reproduce this bug constantly.
It's a variation of comment 111.
I use Thunderbird 1.5.0.2 with debugging symbols.
The Thunderbird profile is on a local ext3 partition, no NFS.
Mail fetching is deactivated.

Ok, here the steps:
-------------------------------------------------------------------------------
Configure your mail account to use the Sent folder from "Local Folders".
It does not matter whether you use an IMAP or POP3 account.
This Sent folder must have more than 2000 messages in it and use at least 1.5 GB
of disk space.

Close Thunderbird and delete the index files of the Sent folder:

rm -rf ~/.thunderbird/$PROFILE_DIR/Mail/Local\ Folders/Sent.msf
rm -rf ~/.thunderbird/$PROFILE_DIR/Mail/Local\ Folders/Sent.sbd

Start Thunderbird again and sent a big email (I used one with 11 MB)
to the account you configured before and leave it in your Inbox.
Prepare 15 emails by pressing the forward button on the big message
in you Inbox and entering a real e-mail adress.
Don't send the emails yet.

The next steps must be done quickly:
Click on the Sent folder of "Local Folders" so Thunderbird will start building
the index.
Click on the send button of all of the 15 prepared mails and wait for a popup with
the message "There was an error copying the message to the Sent folder. Retry?".

Pressing OK will never succeed, but Cancel will bring back Thunderbird most of
the time.
-------------------------------------------------------------------------------

I will attach a backtrace created after the popup appeared shortly.

Using a debug build I get the following messages when the error occurs:

Message Delivery SUCCEEDED!
nsMsgComposeSendListener: Success on the message send operation!
CopyListener::OnStartCopy()
nsMsgComposeSendListener::OnStartCopy()
CopyListener: COPY OPERATION FAILED!
WARNING: event queue chain length is 7. this is almost certainly a leak., file /export/home/s/stfl/mnt/serverhome/cvs/other/mozilla/xpcom/threads/nsEventQueue.cpp, line 553
++WEBSHELL == 71
++DOMWINDOW == 156
++DOMWINDOW == 157
WARNING: NS_ENSURE_TRUE(aRequestingLocation) failed, file /export/home/s/stfl/mnt/serverhome/cvs/other/mozilla/mailnews/base/src/nsMsgContentPolicy.cpp, line 241
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /export/home/s/stfl/mnt/serverhome/cvs/other/mozilla/mailnews/base/util/nsMsgDBFolder.cpp, line 4379
Begin mail message delivery.
End mail message delivery.

I would be more than happy to help solving this bug by providing any
information you need, try patches or debug into code to tell you
about any variable state.

I now can reproduce something similar with an IMAP Sent Folder and without
deletion of the index files.

I still use Thunderbird 1.5.0.2 with debugging symbols.
The Thunderbird profile is on a local ext3 partition, no NFS.

Ok, here the steps:
-------------------------------------------------------------------------------
Configure your IMAP mail account to use a Sent folder of the IMAP account.
This Sent folder must have more than 2000 messages in it and use at least 1 GB
of disk space.

Sent a big email (I used one with 11 MB)
to the account you configured before and leave it in your Inbox.
Prepare 15 emails by pressing the forward button on the big message
in you Inbox and entering a real e-mail adress.
Don't send the emails yet.

The next steps must be done quickly:
Click on the send button of all of the 15 prepared mails.
Copy messages between the sent folder and another folder until
a popup with the message·
"There was an error copying the message to the Sent folder.
Retry?" appears.

Pressing OK will eventually succeed, but at least one window with a progress
bar will remain (sending message to Sent folder) until you press its'
Cancel-button. Then the well-known message "There was an error copying the
message to Sent folder. Retry?" will appear.
Retry will then be successful.

I've tested "version 3 alpha 1 (20060501)" and it seems the probability of 
contention has risen. I have to answer more dialogs when sending the same
amount of messages with IMAP.
I experienced the same problem. I also think I found a way to reproduce the bug constantly (at least on my machine).

Scenario:
Prepare 6 new messages for sending all of them with big attachments (between 4 to 8 MB). All of them uploaded from the disk and not from a previous email - FW.

Effects:
- the biggest email (8.5 MB on my disk) has not been sent. For that email an error message appeared "the smtp server refuse to ..." (if you want the exact message I can reproduce it again). So, for this one the case is closed, no further references to it. 
- all of the others emails have been successfully sent
- all of the others were blocked in the "Copying message to Sent Folder" except for one which has the following message "Sending authenticate login information"

I was waiting for about a half an hour. After that I canceled one of them.
I received the "There was an error copying the message to the Sent Folder. Retry?" I pressed ok once then cancel...the same message. I pressed ok for the second time and I was waiting for about 10 secs and the message disappeared. All of the other windows have been closed except for the one with "Sending authenticate login information".

- All the emails has been successfully copied (obviously except for the biggest one mentioned at the first point)

I'm running 1.5.0.2(20060308) version of Thunderbird on a XP machine.
The SMTP server is gmail, and the IMAP server is a custom one developed by a private company on Linux.

The sent folder is not a local one. I didn't try with a local folder.
The maximum number of server connections is set to 5. 
I wasn't able to reproduce the bug for a single big email, that's way I tried with many.


Offtopic: 
Trying to reproduce this bug I encountered another one (which might be already reported):
I have one email (5 MB) in the "sent folder" (only the headers). During the attachments downloading I pressed "Forward" 5 times. After a while (I suppose after the email has been completely downloaded) five compose windows have been opened.
I pressed send for each, one after another as fast as I could.
All the emails have been successfully sent and copied but only partially. The resulting emails had the size between 100KB to 400KB randomly.

bug 314730 should be marked as a dup of this, as should bug 290059 
Happens for me a lot, not related to recipient or size of emails (a simple message in plain text saying 'test' caused this). Message is saved to sent mail (IMAP) even though thunderbird apparently thinks it wans't even sent. 
possible fix!

I emptied my 'Sent' folder, and it didn't fix it
I reduced the number of cached IMAP connections, this also had no effect.

I went into my account settings, went to 'place a copy in:' section and changed it from the first option ("Sent" filder on: <account>) to 'other' and defined the folder manually - oddly enough, I defined it as exactly what it should have been set to by the other option anyway.

IT now appears to be working - for the moment at least
Ian in comment #136)
> possible fix!
>
> I went into my account settings, went to 'place a copy in:' section and changed
> it from the first option ("Sent" filder on: <account>) to 'other' and defined
> the folder manually - oddly enough, I defined it as exactly what it should have
> been set to by the other option anyway.
> 
> IT now appears to be working - for the moment at least

Still working?
And, a "more ultimate" test, what if you change it back?


Ian in comment #135)
> bug 314730 should be marked as a dup of this, as should bug 290059 
> Happens for me a lot, not related to recipient or size of emails (a simple
> message in plain text saying 'test' caused this). Message is saved to sent mail
> (IMAP) even though thunderbird apparently thinks it wans't even sent. 

Not a good idea unless there is good reason to believe they have the same root cause.  Neither of these bugs have a good analysis to make that judgement and in fact bug 290059 has several conflicting but interesting comments.


Oliver, what is your current situation with this?
QA Contact: esther → composition
Wayne Mery asked me for an update on my comments (see #96).  I haven't seen this problem in a while, though since my last update I've made a few changes that could be masking it:  

1. Switched to Thunderbird 1.5.  
2. The mail server died back in April, forcing a switch to POP.  Finally got it up and running again in July, so I'm back to IMAPS now.
3. I now have a more reliable wireless connection.
4. The new IMAPS server uses maildir directories to improve response time with large folders.
(In reply to comment #137)
> Oliver, what is your current situation with this?

Thanks for asking! I'm not sure how much more useful info I can provide now. I'm using Thunderbird 1.5.0.5.  I believe that I still get timeout's while saving Sent mail to IMAP occasionally. When I do, clicking "Cancel" then "Save" seems to always do the right thing (close the message, save a copy to "Sent").



Wayne asked me to follow up on this...

(In reply to comment #128)
> I am an administrator for the University of Wisconsin - Madison email system. 
> We're running Sun iPlanet Messaging Server 5.2.  We have received many
> complaints from users concerning this problem - copying to Sent IMAP folder
> spins.  It's existed for us since the first version I installed - 0.5 I think. 
> I won't bother explaining the problem since previous posts have explained it
> adaquately.  I will attempt some of the workarounds and report back if I am
> successful.
> 

We've been working around the bug by setting the number of cached IMAP connections to 1, so our "technical" Thunderbird users (the ones that are capable of submitting valuable feedback) haven't reported this issue for some time.

Recently (a few weeks ago) I was having other issues and I reset my TB settings back to the defaults.  I did not reset the cached connections setting to 1; I left it at 5.  I have not seen this bug.  I am running version 1.5.05.

However, our resolution to this problem may not be related to Thunderbird.  I have a user who is still using version 1.0.  He has not changed his settings to accommodate this bug, and he has never experienced this bug in the past few months.  We upgraded our IMAP proxy servers to JSMS version 6.3 a few months ago.   So it is very likely that the upgrade might have fixed the problem.

I will continue to look for this bug and report anything I find.  I have asked my coworkers (running various versions of TB) to set the cached connections setting back to 5 and report to me if they find the bug again.
I also see this regularly with Thunderbird 1.5.0.5. I using IMAPS against the server tuschin.blackcatnetworks.co.uk, and have a manually-defined sent mail folder (called "sent-mail"; from my historical Pine usage :-) on the IMAP server itself. I have two accounts on that IMAP server I use at the same time; each has cached connections set to 2. (I have one more configured that I hardly use; it has cached connections set to 5.)

I usually see it when a message fails to send, and I notice a previous one is blocked at "Copying message to sent mail folder". I work around the problem by pressing Cancel on that original message; this allows the rest to send. I then press "Retry" when asked. The result is two copies of that first message in the sent-mail folder.

I had a suspicion it's related to the IMAP connection timing out, but I can't prove that.

Gerv
Assignee: bienvenu → nobody
Status: ASSIGNED → NEW
Sorry, David. The button's too close to the "Reassign" checkbox :-(

Gerv
Assignee: nobody → bienvenu
Attached patch retry automatically on timeout (obsolete) — — Splinter Review 
I've noticed recently that I'm getting a net timeout error with mozilla's imap server on cached connections - we should be automatically retrying the url in that case, I think...
Attachment #240040 - Flags: superreview?(mscott)
is this the right patch David?
not for this bug, no :-)
Attachment #240040 - Attachment is obsolete: true
Attachment #240051 - Flags: superreview?(mscott)
Attachment #240040 - Flags: superreview?(mscott)
Comment on attachment 240051 [details] [diff] [review]
duh, wrong patch...

much better :)
Attachment #240051 - Flags: superreview?(mscott) → superreview+
I've checked that patch in on the trunk - if anyone seeing this problem wants to run a trunk build from tomorrow and let me know how it goes, that would be great. 
last patch also checked into 1.8.1 branch so it will be in tomorrow's 2.0 beta nightly build.
I have three accounts, all on the same mail server (Courier). The first (primary) account never had any problems, because I had it configured to place a copy in "sent-mail" instead of the default. The other two always sent the mail successfully, but spun on "Copying message to Sent folder". Aborting this and then cancelling the message gave the confusing message "Message has not been sent. Do you wish to save the message in the Drafts folder?" (sidenote: this really ought to be fixed, the message HAS been sent, it just hasn't been filed).

Upon reading these comments I changed the others from the default "place a copy in sent folder" to "place a copy in Other -> same sent folder" and the problem has vanished.

Re Comment #137: changing it back to "place a copy in sent folder" causes the problem to reappear.

Thunderbird 1.5.0.7
(In reply to comment #149)
> [...] cancelling the message gave the confusing message "Message has not
> been sent. Do you wish to save the message in the Drafts folder?" (sidenote:
> this really ought to be fixed, the message HAS been sent, it just hasn't been
> filed).

I think that's bug 227995.
Re: Comment #149 from David
"same sent folder" does not show as an option under *Others*, choices are:
Sent in Local Folders

Pschiffe@aol.com->Inbox, Saved->Choose this folder, Netscape Mail-Draft, Netscape Mail-Inbox, Netscape Mail-Sent, Netscape Mail-Spam, Netscape Mail-Trash; Sent Items, Spam, VOICEMAIL

Local Folders->Drafts, Sent, Trash
 
 
  
bienvenu: it's hard to tell, but I _think_ I'm now seeing this a lot less. Not never, however - it has still happened a couple of times. But it's an improvement. Thanks :-)

Gerv

If you get an fcc request queued behind an other fcc request or copy to the sent folder, you can't cancel that fcc request. This patch fixes that - the initial work was done by laurentiu.dumitrescu@schlund.ro. I'm not sure this patch is quite right, but I wanted to save it off.
Comment on attachment 241944 [details] [diff] [review]
[checked in]saving some work that handles cancelling of multiple fcc's

the reproducible case this fixes is the following:

1. Bring up two compose windows with largish messages and send them both, timing it such that the second one will start doing fcc while the first one is still doing fcc. (IMAP is your friend here :-))

2. Cancel the second fcc, which in effect cancels a pending copy request.

W/O this patch, the progress window for the first fcc will never get closed, because it doesn't ever find out that it was finished. You also will be stuck in a situation where no more copies can happen because we still think we're doing a copy, which will never finish.

I moved the detection of a copy to yourself to AddNewCopySource so that I wouldn't have to duplicate it in a couple places.

I added a check that we weren't already copying to a folder when picking the next copy request to run by keeping track of the active targets. This might fix a whole raft of obscure problems.

Finally, I changed the logic in NotifyCompletion, which gets called when a copy finishes. Instead of running the next copy before clearing the request for the finished copy, I clear the current finished request first (or if there was an error, I clear the request even if it wasn't processed). I also have to check that all the sources have been processed before marking the whole reqeust as processed. This used to happen in DoNextCopy, which was weird, but it worked because we called DoNextCopy before checking if the current request was really processed.

(The copy service breaks copies into multiple sources so that it can handle copies from multiple sources, even though I don't think it ever gets called in that way...that complicates the logic because we need to see if all sources are done before marking a request as processed)

Anyway, I'd like to try this on the trunk, since it's a bit scary. The general approach was proposed by Laurentiu.Dumitrescu@schlund.ro but I had to rework it a bit since he was pretty focused on the fcc to imap case, where requests are unique based on the tmp file being uploaded, but message moves from the same folder all have the same srcSupport, so that complicates things)
Attachment #241944 - Flags: superreview?(mscott)
Attachment #241944 - Flags: superreview?(mscott) → superreview+
most recent patch landed on trunk - I'll let it bake there a bit.
I have seen this on all versions of Thunderbird 1.5, upto version 3 alpha 1 (20061015).

This is while Sending mail (which appears to be OK), but when it goes to copying that same mail to the IMAP folders "sent mail" folder it will get so far and hang.  After canceling, for some reason the message appears on the IMAP server in the sent folder.  I have seen it with almost every attachement that I have sent.  Below is another post on the web that sounds exactly the same as what I have experienced.  If I set it to a a local sent folder the problem seems to go away completely.  At least I have not experienced the issue with my local folder so far.

>I go along with everything so far about the problems with IMAP and irregular >failures in sending copy to sent folder. Most times it is when attachment >involved but occasionally happens with longer email (400 words plus..?) 

this last patch caused bug 357017, so if we want to land this for 2.0, we'll need the patch in that bug as well.
Depends on: 357017
If bug 313747 is a duplicate of this then there might be some useful information in that bug report.
*** Bug 314730 has been marked as a duplicate of this bug. ***
*** Bug 313747 has been marked as a duplicate of this bug. ***
I began to have this issue when I started using an ISP with Courier IMAP server. None of my other 4 imap servers have this problem. And this happens only with larger messages where smtp doesn't come back instantaneously. I have changed the server timeout value to 5 seconds, so I can see the error come back faster. 

When sending larger messages, it connects to the server fine, gets to status: "Delivering mail...", then times out with "Sending of message failed.... because connecting to SMTP server xxx.xxx.com failed. The server may be unavailable or is refusing SMTP...." error. *BUT*, the message has been correctly delivered. 

Maybe the problem actually lies in TB not catching the SMTP finished signal? So it gets confused to what to do next?
I too have been experiencing this problem with version 1.5.0.8. I was able to resolve it however by manually selecting the sent folder on the IMAP server via the 'Other' option in the 'Copies & Folders' section. The problem for me at least seemed to be with case sensitivity. It seems the default behaviour is to send a copy of the message to the 'Sent' folder on the IMAP server. The actually folder name though according to our IMAP server is 'sent'.
For me, the problem seems to alleviate if I don't use ssl on the smtp server setting. Very strange. The IMAP server is Courier-IMAP.
I don't know if this patch has landed on the branch, but I'm seeing this much more rarely now with 2.0b1.

Gerv
For the record, Tbird 1.5.0.9 also hangs in copy to sent folder, worse still is that it happens with very short text only messages along with now occasionally the copy to sent, which used to work despite message box saying it didn't, now doesn't work and one recipient didn't appear to get the first sending - just as well I duplicated immediately after (which worked)
Is this really going to be sorted in version 2 (and I don't mean beta etc versions)?
I have just dug up my Outlook 2000 installation from the Office 2000 set I have and have been surpised at the difference in speed of movement of on screen messages - sending seems to go much quicker also, anyone else noticed that Tbird seems slow in comparison to Outlook (and possibly OE)?
I have the same problem.

Just switched to TB yesterday (1.5.0.9) from Outlook Express. Brand new profile. No extensions.

IMAP has been all problems like this. 

For reference, my mail provider is 1and1.com.  I use TLS to connect, but also have tried SSL and no authentication.

TB often "hangs" when copying to the Sent folder, ~and similarly~, TB may hang when switching to a different IMAP folder.

1) Yes I lowered the cache value to 1, and that does help (but does NOT solve the problem totally).
2) Yes, I turned off IDLE, and that ALSO HELPS (but, again, does NOT solve the problem).
3) Changing the Sent folder to manually select the Imap Sent folder does nothing noticeable.


 I realize the mail server configuration may have something to do with this, but 1and1 is very good about providing setup information, ...and even has setup instructions for TB, and they do not mention having to change either IDLE setting or the CACHE setting.  But again, changing those values does NOT solve the problem.

Outlook Express was rock-solid, NEVER an issue anywhere. I only switched because I wanted to use automatic message filtering (which Outlook Express will not apply mail filters to IMAP).

My DESCRIPTION of when the problem most likely occurs:

For me, I notice that the problem seems to occur (IF it is going to occur...) when (1) sending the first email, or (2) sending an email after a period of inactivity (such as, had not sent an email for maybe a half hour, then send one, notice that probably 40% chance it will fail to copy to Sent properly).  Actually, it copies, but TB does not think so, and the dialog screen stays on-screen.

When the problem occurs, the information on the screen also appears like TB is doing an extra Authenticate for the copy to Sent folder, but it may just look like that since the operation got stuck.  However, I do not notice the word "Authenticate" flash onto the screen dialog box whenever the Copy to Sent works correctly.  Just a thought.  For example, I notice that if I send 3 emails one-after-another within a brief period, the FIRST one of the series will mostly likely have the problem.  I do not remember having the issue with SUBSEQUENT emails a quick series.

Also, in keeping with the "period of inactivity" theory, that seems to also (occasionally) be a problem when SWITCHING between different IMAP folders.  I will occasionally get time-out errors (similar to the Copy-to-Sent problem), and again, time-outs were NEVER AN ISSUE with Outlook Express.

- In regards to Frank Bridgland above, I can verify the Outlook Express is ~significantly faster~ than Thunderbird, both at Sending with IMAP and also searching folders.  Searching folders (even just Subject line) is incredibly SLOW, a snail's pace compared with OE.
there is no need to report this problem for v1.5 - patches so far have been checked in to TRUNK only and the problem is probably well understood.

rpesq, frank, ...
performance should not be the issue here, however, it might be useful to know what you see in task manager's performance tab, Total under commit charge and Total under Physical memory. please post this information

David, sending has been solid for me on trunk.  although, I've had some odd issues, very infrequent, restarting TB after installing certain builds such as 2006-12-27

Wayne, hope the following is what your asking for, if not let me know.

Total under physical memory = 521708
ditto under commit charge = 254836
kernel memory (for good measure!) = 59384

1and1 do my email also and one of their support staff said she used Thunderbird, along with several colleagues and the problem was not experienced by  them.

When is T2 (public release) coming out?
Need to add that these figures (in my last post above) are when using Thunderbird for normal usage and they show little variance during assorted operations. 

They do not show what happens when the problem occurs - this intermittent fault (well it is for me) seems absolutely unpredictable, hence my suspicion it is linked to a susceptibility to server traffic with ISP. (One that doesn't seem to be shared by Outlook or OE...)
TB memory use 43760K

Commit Charge:
Total 225868
Limit 1279700
Peak 274032

Totals:
Handles 4484
Threads 230
Processes 19

Physical Memory:
Total 522544
Available 211936
System Cache 293024


As a comment, I do not think that the discussion on performance (vs Outlook or OE) necessarily reflects increased RAM or CPU usage.  The only way that I can describe it is that OE feels more smooth/efficient. Each task that needs to be performed (load an IMAP folder, send an email, search a folder, etc...) seems to start, execute, and finish quite easily (meaning no pauses, sit-and-spins, good speed, etc...).   I am ~not~ knocking TB at all -- I certainly realize that TB has more features and much more functionality, just making an observation.  I have not tried 2.0, so performance may be improved.

The biggest "performance" issue for me is when switching to a different IMAP folder, they will occasionally time-out and not load.  When this happens, yes it is random just like the Copy-to-Sent issue.  And yes it feels like a bug.  It very well may be related this bug (206408), because folders-timing-out were not an issue with OE.
I suspect the underlying problem is pretty deep. In particualr, I think that Thunderbird is doing things synchronously it should be doing asynchronously. In particular when the user deletes, moves, or copies an e-mail message to a folder TB should not wait for the server to respond before returning control to the user.  These operatiosn should be done in a separate thread or threads. 

This is probably not easy to fix however. :-( 
No, fcc is done asynchronously. The issue is that for a multitude of reasons, the operation can fail, and because the operations are asynchronous, the ui code sometimes doesn't get the notification that the operation has failed.

In 2.0, there have been some improvements so that we silently retry when there's an error copying to an imap folder, which should help a lot of these problems.
If it's asynchronous why does it wait? Why do I see a progress bar at all? Shouldn't it just happen automatically and the view be updated *before* the server responds? 

If you say it's async I believe you, but it seems like TB is not taking full advantage of asynchronicity. The user shoudln't have to wait for the server to respond. 
Yep, we could lie and say everything succeeded instantly, like Outlook Express does. And then we could pop up an error a minute later saying things failed, recreate the compose window, let the user retry, etc. To me, that seems even more fragile than the current approach, which is saying a lot.  I'll never forget disconnecting the network cable, sending a bunch of messages with OE, and it claiming success every time - needless to say, the messages were never sent...

N.B., *You* don't have to wait - you can go do other things while the message is being sent.
Update:

The bug occurred again today, and again:

1) It happened only after I had not sent an email for quite a long time.  TB had been open, checking IMAP all day, but I had not sent an email for three hours.  The very first email that I tried to send, it got "stuck".

2) I can ALSO comfirm that the Authenticate dialog box is the last thing on the screen.
The dialog box has been open for several minutes now, doing nothing, and it reads:

---
Status: Sending authenticate login information...
Progress: [bar at full 100%], with 100% at end of bar
---

So after waiting to see what would happen, nothing did, so I press cancel, and it says `error copying to Sent folder...`
rpesq, you're running 1.5.0.9, right? There are fixes that are in 2.0 that are not in 1.5.0.9 (the .0.x release contain security fixes, for the most part). In particular, one fix is how we handle cached connections that have been dropped, which is very likely what you're running into - we had a cached connection to the sent folder, and it was dropped for some reason (we cache connections for 29 minutes, per the IMAP RFC, but some servers and/or environments don't allow connections to be cached for that long). There's actually a hidden pref that lets you tell TB to only cache connections for XX minutes - mail.server.serverXX.timeout, where serverXX is your imap server, and timeout is in minutes. A small value, like 5, might avoid this problem for you. That means we will assume any connection that's been idle for 5 minutes is dead, and we'll build up a new one.
FWIW, I just saw the same about an hour ago on v2.0b1 b2006120615.  The server leaves idle connections open 31 minutes.

It's possible my firewall's state table expired the session, although I see connections that are a couple hours old at the moment -- I'll set the firewall to be more conservative about discarding states to see if it makes any difference.

This is often the last dialog box I see before the next message says "Failed to copy to Sent folder."  However, USUALLY the copy to Sent folder worked.
Hi David,
Yes 1.5.0.9 (latest public release).

Anyway, just now, the bug occurred, but this time it actually FAILED to copy the message to the sent folder.  (Usually, the message actually does copy, but TB gives the error message that it did not.)

Anyway, maybe I'll try the latest 2.0 beta and see what behavior I experience with it.

Thanks and best regards,
Bob
Going through above postings and my own experiences, we seem to have been experiencing much the same thing and fiddling with cache figures doesn't seem to have much long term effect for any of us, 'cos the problem keeps coming back.

Personally I will now be using Thunderbird to weed out my junk and read email and Outlook 2000 to send email until the public version of Thunderbird 2 comes out.

Ironically I wouldn't have bothered trying Outlook 2000 if it hadn't been for this issue with sending to copy folder - and if version 2 isn't a lot faster I might just switch to Outlook 2000 if it stays as reliable as it has so far with sendings and copies.
Thunderbird is defnitely not as asynchronous as it could or should be. For example, I 'm reading a message and I press the delete key to delete the message. TB should *immediately* display the next message. Instead it spins for a while moving the message to Mail/Trash. It may also attempt download messages and compact a mailbox before it gets aorund to showing me the next message.

I could probably manually click the next message to load it but I shouldn't have to. TB should show the user the next message before it's finished moving the message. 

Perhaps this is a slightly different issue though. 


yes, that's a different issue - the delete is actually performed asynchronously, on a different thread, but we wait for it to finish before loading the next message (the load of the next message is done as a side effect of the delete finishing). yes, it would be nice to load the next message first...and maybe not terribly hard
I know this is off-topic, but...

Really? Please do that! I go through hundreds of messages a day with IMAP and the 1-2 second delay moving from message to message is an enormous frustration. Is there a bug I can CC myself on?

Gerv

Like many others I've been getting incredibly annoyed with this but been trying to live with it. I've voted for this (and similar) bugs, posted about it in a few places and otherwise done everything that I think I can do.

For what it's worth, I've recently changed some stuff with my net connection (8Mb ADSL) which has reduced the incident rate of this copy-to-self bug significantly as a side effect. I thought it worth posting my experiences.

Basically, as you can read in the newsgroup thread from 
Message-ID: <4v9pc5F1aulmbU2@mid.individual.net>
(Google group ref: http://tinyurl.com/ye4tt7 )

my connection was being sluggish sending emails. It turned out that by reducing the timeout of IDENT lookups - or removing the need for them altogether - then emails suddently sent pretty much instantly using Thunderbird.

However, as I've mentioned, the side effect is that the copy-to-self bug has virtually stopped happening; it's happened twice I think in the past few days, compared to several times a day. I can't prove it but I think the ADSL was being used semi-heavily at these times, too.

A friend conjectures... "I wonder if Thunderbird opens a new IMAP connection to do copy-to-self and they time out?"

I hope this helps; I've been very, very frustrated but want to support the project. I nearly quit a few times because I got sick of it; hopefully this will point a coder in the right direction!

Regards, Peter

version 3 alpha 1 (20070107)
Never had this problem until now. My sent emails do not end up in the SENT folder, and it looks like a regression between 28/12 and 06/12
(In reply to comment #186)
> version 3 alpha 1 (20070107)
> Never had this problem until now. My sent emails do not end up in the SENT
> folder, and it looks like a regression between 28/12 and 06/12
> 

I meant regression between 28/12 and 06/01, although rebuilding index of sent folder fixed it. It broke while sending emails with 5megs+ attachments.

I'm one of the mail admins at Ghent University.  We are seeing the same symptoms.  Our setup is a more complicated so were are not sure if this if the above bug.  Our setup is cyrus imapd 2.37 behind perdition proxies and that behind an linux virtual server setup. 

I'm almost sure that it is a thunderbird related problem because user not using thunderbird haven't had the problem.

If somebody knows a way to reproduce the bug I could help debuging it.   
See #111 for a description on how to reproduce the problem with copying to the sent folder. Limited uplink bandwidth helps reproducing the problem.
Note: the problem is most likely not related to IMAP.

I tried to repoduce but it didn't hang.  (Although I'm trying this from a very slow internet connection, at the office I can't follow the steps because the network is to fast.)

An other user tried to adjust the setting where you can say 'save a copy in other folder: '.  But to him TB spins even more then.
I see this occasionally, but thought it had something to do with the folder automatically compacting at the same time.
see tb_rudy for client side imap log too please
Attached file Client side TB log — 
See 251076: server side imap capture
Sorry about the several comments.

https://bugzilla.mozilla.org/attachment.cgi?id=251077
https://bugzilla.mozilla.org/attachment.cgi?id=251076

I've attached server and client side imap logs.  The client side also has some output/input from other servers.
Attachment #251077 - Attachment mime type: application/octet-stream → text/plain
Rudy, is that with 1.5.0.x? That looks like a problem that has been fixed in 2.0 b1
(In reply to comment #177)
> FWIW, I just saw the same about an hour ago on v2.0b1 b2006120615.  The server
> leaves idle connections open 31 minutes.

I increased the server timeout to 32 minutes, and set my firewall to be a little more conservative about leaving hanging sessions open, I haven't seen this issue since.

However, my reading of the IMAP protocol specifies that the server may close the connection at any time, and that the client should not display an error unless the client cannot reestablish a connection, so there is still an outstanding issue if TB cannot cope with the server dropping connections prior to 1800 seconds.
Yes, everybody here is using 1.5.0.X.  I could ask some of them to try 2.0 b1.
David, I see that in 2.0b1 the following bug is fixed: Crash when cancelling copy of sent mail (large attachment) to Send folder.

Some of our users have that problem too, but in the most cases TB doesn't crash.  
I don't know about anyone else using 1.5.0.9 but suddenly I am getting an increase in this error cropping up. Before it came for once, maybe twice in a session or two then disappeared for varying lengths of time. 

The last fortnight has seen a recurrence of this error, almost becoming regular. Which it wasn't before - and I haven't added anything new to Thunderbird - except for update to 1.5.09. I allowed the update to run when asked if I wanted the new update. I may not do that again. 

Normally I download the new version and install from saved exe on my hdd, which was what I did for 1.5.0.8 back on 9 Nov 2006. Now up to then and shortly after that, the error was infrequent. Now it is more frequent. Maybe I ought to uninstall 1.5.0.9 and reinstall 1.5.0.8?

Anyone any ideas?
hope this will get fixed soon!
I have tried 2.0 b1 and I just got the error.
Well, maybe this this is even server dependent, because for my account at work this never happened!

The imap server at work is::
Microsoft Exchange Server 2003 IMAP4rev1-Server, Version 6.5.7226.0

The server with which im getting those errors is::
courier-imap                       4.1.1.20060828-2

Maybe this helps?

Currently my IMAP email server at 1and1 just isn't working reliably (no they don't have anything on their website to check this..) and my ISP PlusNet seems wrapped up in assorted server problems, so some of my problems with Thunderbird may be outside it's remit.
But it is disconcerting to read folk posting this error seems to turn up on 2.0b - if the problem is still surfacing on 2.0 it starts to look as though the problem is inbuilt - this from a purely beginners, non-tech viewpoint.
I'd like to see some reassurance posted here about progress - is there any?
running 1.5.0.9 on winXP, disabled IDLE support and modified the manual copy to folder thingie.

guys this is a serious thing. please fix it
Same here - very serious problem and only present in TB - Tried the 2.0 build and I also see the same problem.
Please, please look into this :-)
anyone seeing this with a 2.0 build, feel free to attach or send me an imap protocol log generated with 2.0 demonstrating the problem - follow these instructions:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html
This has been mentioned in passing above, but I'm realizing the priority is changing for me.

The "sent" problem seems related to the "copying message to Drafts folder..." problem.   In fact that latter is more of a headache and more worth fixing.

When TB tries to autosave a message to the (imap) Drafts folder, it will often hang in a similar way to the "sent" problem.

With the "sent" problem, at least the message is actually copied to the sent folder, so you just have to cancel out of the dialogs quickly.

With the "drafts" problem, you're sitting there actively writing a message, and it gets stuck on autosave, and you then have to manually create a new message (by compose or reply) and copy and paste what you've written so far.  This is a major pain in the ass.

But I don't want to turn off autosave, since that's a core advantage of a good email client.

Anyone else feel this is perhaps even more of a problem than the "sent" behavior ?
well, this is only partially true ... most of the time canceling the dialog will really end the pain, but there are times when the message wont get copied into the sent folder and is kinda lost forever!
I dont like not being able to look up some things in the sent folder or to rely on peeple actuall quoting the last mail ...

But i do think that this is actually another result of the same underlying bug ... BOTH should be fixed soon - how many votes does a bug need to get noticed?

FWIW...

Yep, have also had the failed to copy to sent folder message meaning just what it said on the wrapper.  Have also had the very occasional failure of saving to draft folder (countable on two fingers so far..) By far and away the major problem has been failure/hanging saving to sent folder.  Which makes me wonder..

Is there a situation where it breaks down that either the majority of failures are either for copy to sent folder OR save to draft folder?

Does anyone over a period of time have exclusively one or the other problem and if so does it mean anything?

Have spent time trying out Outlook (faster but...) and even with the imperfections of Lightning 0.3 have found I'm happier with Thunderbird. :) Now if someone can nail this current bug life would be better...especially if the speed could be racked up. Is there a bug page for speed?
 get the same. Some notes:
1) When fresh boot and fresh TBird start, it works "normally" for a few emails, then resumes this behaviour
2) When I see the "saving to sent" dialog churning,If I delete a message the copy completes normally. I actually leave some spam in my inbox now, and periodically delete one to "flush" my Sent items churns.
3) Items always get copied to sent, but TBird seems to not "notice" this.



Maurice, if you're using IMAP with a 2.0 beta build, a protocol log might be helpful:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
I had not been having problems recently with 1.5, but I tried 2.0 beta 2 today just for kicks.

The ~VERY FIRST~ email that I sent, failed to copy to Sent folder.  In fact, it just sat there at 100% and did nothing, I finally had to cancel it manually after like 10 minutes of waiting to see what would happen.

Again, like before, the message DID actually copy to Sent, but TB did not know that.

The symptoms were identical, except that with 1.5, it had the courtesy to say that the Copy Failed.  Here in 2.0B2, it just sat there.

I will try to generate a log for you guys, but honestly if you want more people to do that, you really should consider making loggin an about:config entry or an Option Menu entry, either of which would make logging easier.  You can easily drop the log file in the profile directory.
Just curious, does the log capture any private data (passwords, etc)?
Re about:config - yes, of course, that's highly desirable, but unfortunately that requires changes to NSPR that the NSPR module owners don't seem to want to allow in. There's been a patch for a couple years, iirc.
the log specifically does NOT record passwords - but it does record the message bodies you download, and the messages you send, if they're copied to the imap sent folder. However, if this is easy to reproduce, you should be able to do it with a test message.
I have enabled logging.  As others have noted, this bug is NOT easy to reproduce.  It may happen frequently, or as I said above, I had not seen the bug once for probably past 10 days.

(In reply to comment #214)
> Re about:config - yes, of course, that's highly desirable, but unfortunately
> that requires changes to NSPR that the NSPR module owners don't seem to want to
> allow in. There's been a patch for a couple years, iirc.

bug 94480, bug 193873 and a variation, bug 229173
Hi David,
OK, it screwed up again.  Where/Who can I email the log?  I do not want to post it publicly for obvious reasons.
Bob, send it directly to me. I will delete it after I look at it...
(In reply to comment #211)
> Maurice, if you're using IMAP with a 2.0 beta build, a protocol log might be
> helpful:
> 
> http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
> 
I just tried this.
First off the document referred to shows debug levels from 0 to 4, NOT 5, so I created the bat file with the following contet, adn saved it as "runtbird.bat":

set NSPR_LOG_MODULES=protocol:4
set NSPR_LOG_FILE=c:\tbirdlog.txt
start thunderbird.exe


Next I quit TBird ( Version 1.5.0.9 in Windows XP MCE)
I then ran my bat from a CMD prompt
Thunderbird starts.
A log file appears, of 0 bytes length.
I then sent an email to myself.
NOTHING is in the log!

However, and this is REALLY INTERESTING:
If since I started TBird with this bat file, the sending error does not happen!
So, I quit, and tried starting it with the "regular" Windows shortcut:
"C:\Program Files\Mozilla Thunderbird\thunderbird.exe"

It runs, and now there is NO ERROR ON SENDING!

Somehow turning on logging seems to have changed something.

This is severely flaky.

1) The logging command in te example uses a debug level of 5 which is apparently unsupported
2) Running this bat to start TBird seems to clear up the problem ( Yay!)
3) The resulting log file is always an empty 0 bye file




set NSPR_LOG_MODULES=protocol:4
set NSPR_LOG_FILE=c:\tbirdlog.txt
(that does nothing, so I doubt it changed anything :-) )

that's supposed to be 

set NSPR_LOG_MODULES=IMAP:5
set NSPR_LOG_FILE=c:\tbirdlog.txt

<sigh>
So why does it say at:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Logging level

The 5 in the first variable above specifies the level of logging you want - a lower number reduces the amount of information that is logged to the file.

The numbers are supposed to have the following meaning:

PR_LOG_NONE = 0, /* nothing */
PR_LOG_ALWAYS = 1, /* always printed */
PR_LOG_ERROR = 2, /* error messages */
PR_LOG_WARNING = 3, /* warning messages */
PR_LOG_DEBUG = 4, /* debug messages */
I just changed the bat file to include:
set NSPR_LOG_MODULES=protocol:5

Same thing. Empty log file

Next suggestion?

The problem isn't the *5*, the problem is the *protocol* --

  set NSPR_LOG_MODULES=imap:5
                       ~~~~
I'm also not really interested in a log generated by 1.5.0.x - there have been a number of fixes in this area for 2.0. I'm really interested in finding out if 2.0 beta builds still have issues, and what those issues are.
Doh! <smacks head>
Now we get a log.

Then I read the message above, so I was wasting my time.. as this is not useful I guess.

BUT: The good news is that whatever this did fixed the bug seemingly.
I can now send messages, and no waiting for the dratted spinner to go away

So, for that: Thank you.
 
I left the logging running for about 5 minutes.
I now have a 5MB file!


David,
I emailed you my log a few hours ago.
bob
Hi ho, version 2 beta 2 (20070116) performs just like version 1.5 - the only questions remaining 1) how many more times will it hang sending to copy and 2) will there be times when failed to copy means exactly what it says.

David, do you want any more logs?


Frank, yes, a log would be helpful. My recollection is that your network was fairly flaky, with lots of dropped connections, but a 2.0 log would be helpful.
For me, Version2 beta 2 still does hang occasionally, but it doesn't hang for more than about 10 secs - i.e. not permenantly, like 1.5 used to.
One idea toward resolving this might be for Thunderbird to check every 5 secs if the IMAP copying situation has changed, and if it hasn't, to automatically cancel it and retry (as manually doing this usually resolves the problem, it's just that it's a pain).
Incidentally, how many of the people experiencing this problem are using IMAP server provided by 1and1? Their service is pretty shoddy even at the best of times, and tho' Thunderbird is clearly part of the problem, 1&1's mail service is pretty sluggish too. Perhaps those who are, like me, still experiencing occasional hangs are using a shoddy IMAP service?
Thanks David for working on resolving this - it's a really major bug for us IMAP users and I for one appreciate your hard work in ending this hassle! :-)
Chris
I see the 10 second delay - that's about how long it takes us sometimes to figure out that the connection to the server has gone bad. That's one of the things I fixed.
I can share some insight too.  As I said before our imap servers are behind a LVS setup.  We could reproduce the bug by waiting until the LVS killed the connection because there was no activity.    A colleague could reproduce it easily by setting the timeout very low.

We have now configured our xinetd to keep the connection alive. 

One strange thing though.  When our perdition kills a connection (that is by default after half an hour) TB doesn't hang because (we think) perdition shuts down the ssl connection.  But LVS doesn't handle this.


defiantly still happens in thunderbird 2beta2 - binary build , config created from scratch, not upgraded from a 1.5 config.
Rudy, TB only caches connections for 29 minutes, so if they're kept alive for 30 minutes, we shouldn't get any dead connections.

Ian, http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Ian, have you tried a recent 2.0 beta 2 nightly?
I asked my college and he says:

LVS keeps the connection open for 15 minutes.  We now have our xinetd send a packet every 10 mintues so LVS always has the connection open.

I hope this helps
Hi,
I'm still experiencing the occasional issue here... but I tried to set up logging but didn't have any luck (I set it to "imap:5" etc - no joy). It's just that the file that it's supposed to create doesn't exist.
I assume you'd like more logs, so I'll keep trying, but am I doing something wrong?
Chris
Sorry sorry, I've sorted out logging... Now it's just a case of getting the darn error to re-occur! grrrr...
Here is my view of problem, what I did to fix it, and my theory regarding what underlies the bug.

Brief background:  I own the server with IMAP.  Problem occurs with Thunderbird on a Linux machine.  Does not occur with Thunderbird on OS X machine.  I upgraded IMAP software (was 3 years old) and played with both secure (port 993) and plaintext (port 143) connections.  No change.  Therefore, I rule out quirks in IMAP server as the cause.

I ran tcpflow on both successful and failing connections.  The results are pasted at end.  Thunderbird is prepending the folder name with a caret (^).  Also note that comment #74 shows the same problem (a prepended caret).
https://bugzilla.mozilla.org/show_bug.cgi?id=206408#c74

The account's IMAP server directory is in a Mail folder, that's why you see "Mail" included in the folder name of my tcpflow output.

How I fixed the problem:  I simply "jiggled" the settings in the "Copies & Folders" configuration.  Specifically, I changed the values of "When sending messages, automatically...", which caused the errant caret to go away, and all to behave properly.

The underlying problem: This is a (probably very bad) guess mind you--when the string referring to the folder is built (e.g. "Sent") there is some sort of buffer overflow occuring.  That would explain both the corrupted string and the IMAP commands that the client is sending which appear to be totally unrelated to the commands which are sent during a good exchange.

Anyway, below is the TCP traffic related to sending a message, both good and bad 

Bad connection looks like this:
==============================================================
MESSAGE FLOW FROM CLIENT TO SERVER DURING BAD SEND
-----------------------------------------------
DONE
19 list "" "Mail/Mail^Sent"
20 subscribe "Mail/Mail^Sent" 
21 IDLE

MESSAGE FLOW FROM SERVER TO CLIENT DURING BAD SEND
-----------------------------------------------
18 OK IDLE completed
19 OK LIST completed
20 NO SUBSCRIBE failed: Can't subscribe to mailbox Mail/Mail^Sent: no such mailbox
+ Waiting for DONE
==============================================================


Good connection looks like this:
==============================================================
MESSAGE FLOW FROM CLIENT TO SERVER DURING GOOD SEND
-----------------------------------------------
1 capability
2 authenticate login
amdnaWJzb24=
SDAwdA==
3 append "Mail/Sent" (\Seen) {382}
Message-ID: <45E7B097.7080506@jamesgibson.us>
Date: Thu, 01 Mar 2007 22:05:27 -0700
From: "James G. Gibson" <jgibson@jamesgibson.us>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To:  tgibson@augustcouncil.com
Subject: good send
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

this is a good send

MESSAGE FLOW FROM SERVER TO CLIENT DURING GOOD SEND
-----------------------------------------------
* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] opencentric.com IMAP4rev1 2001.315rh at Thu, 1 Mar 2007 22:05:28 -0700 (MST)
* CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS STARTTLS AUTH=LOGIN
1 OK CAPABILITY completed
+ VXNlciBOYW1lAA==
+ UGFzc3dvcmQA
2 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User jggibson authenticated
+ Ready for argument
3 OK APPEND completed


David: does that log help? It looks really interesting to me...

Gerv
JFYI,

This is NOT an IMAP problem only, since this happens to me once in a while (although less frequently these days) with local, non-IMAP, accounts.

BTW, why does it have to spin for signed and/or encrypted messages whilest one needs to type in the Password for the Security Device, when sending (or auto-saving) the message. That's a real annoyance. In particular since the Progress Meter in the Status Bar is spinning also.
Sorry, forgot to mention the platform.

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.10) Gecko/20070217 SeaMonkey/1.0.8 - Classic Theme

Thx, Todd - The '^' is our placeholder for the imap hierarchy delimiter, i.e., the character that separates a folder from a sub-folder in a path.  Somehow, that got into the uri for the fcc folder. We also got the online directory into the URI somehow - it would have been interesting to see what the fcc uri in your prefs.js looked like, and figure out how it got set to the bogus value. It should have looked something like "user@server/Sent" and instead it looks like it was set to "user@server"/Mail^Sent". We should not have pre-pended the online directory (I'm just guessing that you set the online directory field - perhaps the server returned it as the personal namespace?"
Here's some additional post-mortem information.  On the server I found the Mail^Sent listed in .mailboxlist.  It would have been inserted by some version prior to the 2.0 beta.  With 2.0b2 I briefly tried to recreate the problem by playing with the online directory setting, the checkbox for folder/sub-folder IMAP capabilities, and creating folders/mailboxes.  My tests were by no means exhaustive, but to its credit the beta kept me out of trouble.

How about this for an open question:  What effect might *other* mail readers have on Thunderbird's performance?  For example a user might revert to some Web-based tool for accessing email when the user isn't on his/her usual computer.  I noticed that Thunderbird assumes that the listing in .mailboxlist is valid.  That is, .mailboxlist may have an entry for a directory/mailbox which has been removed from the server but Thunderbird assumes the directory/mailbox exists on the server.  I'm assuming .mailboxlist is managed by Thunderbird directly but perhaps I'm mistaken.
bugzilla-daemon@mozilla.org wrote:
> This is NOT an IMAP problem only, since this happens to me once in a while
> (although less frequently these days) with local, non-IMAP, accounts.
>
> BTW, why does it have to spin for signed and/or encrypted messages whilest one
> needs to type in the Password for the Security Device, when sending (or
> auto-saving) the message. That's a real annoyance. In particular since the
> Progress Meter in the Status Bar is spinning also.

This week it happened to me while saving to the local Unsent folder...  You imagine what kind of problems this brings.

TB 2beta, Windows XP, if that matters.

I have already done every workaround I saw on google searches, and none fixes this problem for ever.

BTW: A solution to BUG 59308 would probably also solve this after all, since one reason for Maildir folders is to avoid locking at all.

Uploaded an e-mail that triggered the spinning, FWIW.

I have it spinning here right now, since half an hour.

+--------------------------------------------------------+
|Sending Messages - Reserved for Drunk Drivers :-)       |
+--------------------------------------------------------+
|   Status:  Copy complete                               |
| Progress:  _____#####_____________ (spinning)          |
|                                                        |
|                                               Cancel   |
+--------------------------------------------------------+
Uploaded a screenshot of the spinning belonging to the example message that triggered the spinning.
Attachment #257724 - Attachment mime type: message/rfc822 → text/plain
FWIW, I opened a HTML Message composition window into which I pasted the screenshot, dragged it out from there into C:/Temp and uploaded the image to Bugzilla. Once that was all done I aborted the HTML Message composition window by clicking 'x' in the upper left. This made the "spinning" widget go away.

s/left/right/

This is a major problem for me.  It occurs with TB 1.5.0.10 (20070221) on WinXP (Tablet).  I have 3 IMAP accounts setup, and at times all of them display this behaviour, but some more than others.
"Me too"
thunderbird-1.5.0.10-1.fc7, linux, 1 imap account, Sent folder is 230mb. This is a new bug, 1.0 worked ok.


Additional info: Sent folder is local. Cancelled the mail and attempt to save it to Drafts (on server), it hangs too.
Restarting tbird and sending again same message usually works.
well, if u ask me this can easily be fixed if every time Thunderbird tries to initiate some action it shall test the current connection and login again if there aint any good response and i bet the noop command will be the best tool for that.

Ive been looking at this for quite some time now [because it only happens every now and then] but every time this happens i can find a timeout in the server logfiles!
So just verify the open and still alive connection before Thunderbird tries to copy the message to either sent of draft folders and everything will be fine.
Flags: in-testsuite+
Flags: blocking-thunderbird2?
Flags: in-testsuite+
Flags: blocking-thunderbird2?
Well folks, this is weird ... i really wanted to know what goes wrong when this bug appears so i installed this NetworkMonitor [http://www.m-software.de/java-network-monitor.jsp] which basically forwards all traffic and prints a copy of it into the console ... this way i could have read up on the last protocol lines after this bug happend again ...

BUT the weird thing is that since im sending Thunderbird through this app i never had to face this i cant copy your message bug again??!!!

I kinda really dont get it!
What happens here?

Where an IMAP server sits behind a load balancer or CSS, that device may reset IMAP connections it thinks are "unused." I have seen that, with the 1.0 codebase at least, users will get a hang on the "Sending Authenticate Login" message https://bugzilla.mozilla.org/attachment.cgi?id=250524 if the TCP connection to IMAP gets reset when Thunderbird issues a "DONE" command to bring the connection out of IDLE in order to append the message to the IMAP Sent folder. This observation may not apply to the Thunderbird 1.5 or 2.x codebases -- I have not succeeded in capturing a network trace against the current version.
I am getting this problem on TB v1.5.0.10 on MacosX v10.4.9.

TB has a number of accounts configured. The first account, sent works fine. On the third account, copy to sent folder hangs forever.

Deleting the corresponding folder inside ImapMail and redownloading the mail from scratch makes no difference, the problem remains.

It may be that this bug was fixed for the first mailbox, but not for subsequent mailboxes.

TB 2.0.0.5pre

This bug is not just IMAP related as I am using POP.

I have switch on the option to copy the message to the folder in which the massage is that I am replying to. This seems to cause a lot of these "Can't copy" problems. This is not really folder related as it occurs to more than 1 folder.

If it fails to copy, it does not time-out and therefore cancelling is the only option out.

What frustrates me the most is the fact that the "Cancel or Retry to Copy" option does not work either. Cancelling takes me back to the draft screen and Retry as well. What is the retry suppose to do?

Only option left is to save as draft and copy manually. 
I switched to v2 a few weeks ago, and I have to say the bug appears far less frequently now.  I think I've only seen it 2-3 times total, compared to 2-3 times per day with 1.5.x.

Still on 1and1 imap.

Keith
Attachment #241944 - Attachment description: saving some work that handles cancelling of multiple fcc's → [checked in]saving some work that handles cancelling of multiple fcc's
I don't know if there are any differences in 'root code' or whatever but I have found since switching to SeaMonkey 1.1.2 and lately 1.1.3 that the problem has yet to occur - am still also on 1and1 IMAP. This may simply be tempting fate, will post back if problem turns up....reason for switching was that problem still recurred on T2. SM seems faster than T and F .....
ALL

To address this more efficiently, because we know there are multiple problems with similar symptoms, if you still have a problem please file a NEW bug for your case. David would like to see each case tracked separately in its own bug, so please don't hijack someone else's bug. Just file your own and don't worry about duplicates for now.

File the bug in product+component core:imap or core:pop depending on the account, and also state it in the bug topic. For imap attach a protocol log (or email it to David with the bug#) using http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap and make sure you replace "protocol" as follows
  set NSPR_LOG_MODULES=imap:5

David asks in comment 225, please report only problems against version 2 (there are several fixes for these problems in v2) or higher, i.e. trunk build from  http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/  Also make sure you set the version field in your bug report.

So that we can work to close this bug out, please don't comment further in this bug unless it relates to a pending fix or open question posed by David or someone else.  Thanks.

Finally, the knowledge base does not have enough good information and will benefit from your solution/problem experience. Please consider making an addition to one more more of the following on any aspect of this problem:

 http://kb.mozillazine.org/Cannot_send_mail
 http://kb.mozillazine.org/Connection_errors_-_SMTP

http://kb.mozillazine.org/Category:Sending_and_receiving_mail_(Thunderbird)
 http://kb.mozillazine.org/Performance_-_Thunderbird

You might also discuss your problem in one of the newsgroups or forums http://www.mozilla.org/support/
I have filed a new Bug 390136 for the POP related cases as requested by Wayne. Not sure if it is in the right location as I have no idea where to find  product+component core:pop.
sorry, i meant to write networking:pop, that would be in product=core https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
closing FIXED.  patch attachment 241944 [details] [diff] [review] and corresponding patch from bug 357017 landed on branch MOZILLA_1_8_BRANCH 2007-01-04 bienvenu%nventure.com mozilla/mailnews/base/src /nsMsgCopyService.cpp 1.51.2.1.  

Thunderbird 2.x and seamonkey (1.1.3? and above) have the fix, namely two sends and copies going at the same time, affected by the copy service used by both pop3 and imap.


If you still have a problem, please file a new bug and be specific about your configuration (pop3/imap/accounts) and steps to reproduce.  If imap, please attach protocol log.  More details in comment 264.
Status: NEW → RESOLVED
Closed: 21 years ago → 17 years ago
Resolution: --- → FIXED
This bug claims to be fixed, but the problem is still fully reproducible 
in SeaMonkey trunk nightly builds in January '08.  There is no noticeable 
behavioral difference with or without this fix.  I will file a duplicate.
In defense, I claim that I've downloaded the nightly build from 2007/12/12, and it solved my problems once for all.  I did not upgrade any time later, so maybe the bug was reintroduced, or we are talking about another bug with the same symptoms.
Product: Core → MailNews Core
I fixed this problem, I didn't have it before, but when I got it, it was annoying. I am running the latest version. The messages are sent to the folder, yet the window hangs. After about an hour or so of looking into it and trying many things, I fixed it. I went to account settings, copies and folders, I found that setting a custom path, to the same folder (your sent messages folder), fixed it for me, also, I clicked the "Show confirmation dialog" box. That is what I did, and I no longer get the hanging window.
I am having this problem since TB3.0 RC2 (for sure, maybe RC1 already).
Tried the folder workaround, no success.
Tried the max connections setting workaround, no success.
A colleague of mine has exactly the same problem
Avdo, are you saying this is still happening in the official release of TB3?

Are you using IMAP or POP3? If POP3, does compacting the folder solve the problem (for a while)?
(In reply to comment #271)
> Avdo, are you saying this is still happening in the official release of TB3?
> 
> Are you using IMAP or POP3? If POP3, does compacting the folder solve the
> problem (for a while)?

Yes It is happening in the official TB3. I have been using TB3 since beta 2 and I noticed this the first time in RC1 or 2 (not sure since RC2 came out a couple of days after RC1).

I am using both POP3 as IMAP: I have 2 IMAP mailboxes, and 1 POP3 mailbox that goes into 'local folders'. I dont use the POP3 account often to send mail though.
For all three addresses/mailboxes I use the same SMTP account (background info).

Once the 'copying message to sent folder' hangs, it will occur every time until restart of TB3. In RC2 it could happen that I had to reboot the whole system.
When it occurs it does not matter which account I use to send mail from. Even the local (POP3) account will hang on that message, even though it just has to write it to the local disk.

Restarting thunderbird is inevitable.

I still have not figured out what exactly triggers this behavior of thunderbird.  I think it mostly happens after I wake up the machine from stand-by. But I'm 100% sure it also happens arbitrarily.
I'm still seeing these in SeaMonkey, most recently, 2.0.1 Mac.  Seems like it got worse under 2.0.1.  I just noticed 2.0.2 out yesterday and upgraded, so will keep watching.
I'm still seeing these in SeaMonkey, most recently, 2.0.1 Mac.  Seems like it got worse under 2.0.1.   It just hangs with the copying window up, and the copy seemingly complete.  I just hit cancel to move on with no other adverse effect.

I just noticed 2.0.2 out yesterday and upgraded, so will keep watching.  Is there anything I can look at while this hang is happening?
My mail server had some time issues (the time was lapsing faster than it should)... Since i resolved this issue, i have much less problems... However, thunderbird should not hang on it...

The status of the bug is "RESOLVED"... Anyone have the rights to change it to unresolved?
All, 

A specific aspect of this problem is resolved in this bug, so the bug remains closed as FIXED. The proper course of action is to find an open bug which addresses the issue or file a new bug. I suspect there are several bugs, but specifically bug 413240 sprung from Comment 267 ... in fact it is clearly marked a dependent/follow if you look at the top of this bug.

Please cc on 413240. And please comment there *only* if you have new information not already stated in the bug which will help lead to a patch.
Whiteboard: please do not comment: see comment 266, comment 276
See Also: → 1745130
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: