Closed
Bug 298974
Opened 20 years ago
Closed 16 years ago
When I send a message, it is sent but not saved to IMAP, hence content is lost
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: gustep12, Unassigned)
Details
(Whiteboard: closeme 2009-07-09)
Attachments
(1 file)
41.12 KB,
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
I keep having this problem *very often*, but I found a workaround. My IMAP
accout is also pretty full, maybe that has something to do with it?
When I have just written a message and click the "send" button, I see the error
message which says approximately "Your message has been sent but could not be
copied to the Sent folder. Return to Compose or Discard?"
The workaround for me is as follows: Ignoring the compose window and error
message for the time being, I go to the folder view (main) window. There I
change the folder that is currently highlighted, i.e. if the highlight is on
"Sent", I might click on "Inbox", or the other way around. That's all. I then
return to the compose window and send the message again, and this time it is
stored in the sent folder as expected.
Can this be fixed? It is really annoying.
This happens on both my home PC and my office PC. My feeling is that this has
something to do with folder refresh and incoming/automatically sorted/filtered
messages or something, because apparently refreshing the IMAP folder contents
right before sending is all that's required to solve this bug.
Reproducible: Sometimes
Steps to Reproduce:
1. Have a 90% full IMAP account of ~ 100MB storage space.
2. Set up automatic message filtering & deleting into trash etc.
3. Have some "filtered" emails come in while you write a long message
4. Click "Send", and you get the error message (sent but not saved)
5. In the main window, refresh the folder view, then try sending again
6. This time the message it is saved
7. Do it wrong, and the message is lost - you retain no copy. This sucks!!!
Comment 1•19 years ago
|
||
Sebastian, have you updated to Thunderbird 1.5 yet? There have been several fixes for similar bugs -- bug 123063, bug 163951, bug 287658.
If you are no longer encountering this problem with a current build, please mark this bug: Resolved | WorksForMe
Comment 2•19 years ago
|
||
hello,
i have the same problem with my thunderbird version 1.5.0.2 (20060227).
workaround works, but is annoying ...
please fix it.
Comment 3•19 years ago
|
||
An imap protocol log of a session where this happens, and a session with the work around, might be helpful:
substitute IMAP for "protocol" in these instructions.
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Comment 5•19 years ago
|
||
played a little bit with the log....
first got MANY messages like this (but with different foldernames at the end):
0[274680]: exceeded connection cache limit:SERVERBLABLA>.INBOX.Privat
0[274680]: queuing url:SERVERBLABLA>.INBOX.Privat
0[274680]: considering playing queued url:SERVERBLABLA>.INBOX.Privat
0[274680]: creating protocol instance to play queued url:SERVERBLABLA>.INBOX.Privat
so I reduced the number of parallel cached connections for the imap account.
Now these messages have been reduced, but still are not gone.
Is this a problem? Or should i ignore these messages?
BTW: After reducing the maximum connections, i couldn't reproduce the problem til now, but still trying...
Comment 6•19 years ago
|
||
you mean you reduced the number of connections TB will cache, e.g., from 5 to 4 or less? It's odd that would help.
A full log (sent privately to me, if you like), would be interesting. If you had the connection cache set to 5, it's surprising all the connections would be busy, but a log might explain that. Do you have TB set to check a lot of/all folders for new messages because of server side filters?
Comment 7•19 years ago
|
||
yes reducing the concurrent connection from 10 to 4 on all 4 imap accounts improves perfomance and solves the copying to sent folder.
one account has around 10 subfolders with again 5 sub-subfolders. so all in all 50 subscribed folders. This is the only account where i noticed problems.
btw: where can i set which folder TB should check for new messages? does it mean that, if i subscribe a folder, it will be checked for new messages? or are these settings two different pairs of shoes?
Comment 8•19 years ago
|
||
Are you running against a courier imap server? Are these accounts on different servers, or on the same server?
There are two ways to check folders other than the inbox for new messages:
setting "mail.check_all_imap_folders_for_new" to true will cause every imap folder on a server to be checked for new mail whenever check for new mail is run on that server. This will be true for newly subscribed folders as well, since it checks all folders.
Or, you can use the property sheet on a particular folder to just have that folder checked. Newly subscribed folders will need to be configured to be checked using the folder properties.
Comment 9•19 years ago
|
||
yes it's a courier imap server. 3 of 4 imap accounts are on the same server.
i took a look in my properties file and mail.check_all_imap_folders_for_new is set to true.
Comment 10•19 years ago
|
||
ah, the perfect storm. Do you know what the max connections per ip address is for that courier server? The default is 4, which would be shared between the three accounts, and would cause us problems. Checking all folders for new messages tends to keep connections busy as well...I'm happy to look at a protocol log of a failure session, if you like.
Comment 11•19 years ago
|
||
cat /etc/courier/imapd.conf
# Maximum number of connections to accept from the same IP address
MAXPERIP=20
the problem with the log is, that there are many personal information in it and i can't be sure to filter them all out, because the log file has increased very much in a very short time ^^. the only thing i could admit is, to search the log for any weird stuff, e.g. mentioned in comment #5.
Comment 12•19 years ago
|
||
yeah, no problem, I understand about the personal issue. You could filter out the contents of the messages you read, or just create a log of a session where you don't read any messages. But if the subjects and senders of messages are sensitive, or even your folder names, then it's not really worth the hassle, because studying the log is very time consuming for me, and if you've accidentally removed something useful, it would be a waste of time.
Comment 13•19 years ago
|
||
btw: setting the maxperip setting to 1, result in a freeze of TB. first, some msgboxes appeared, which show that the maximum no. of concurrent connections has exceeded, then TB freezes...
nothing special in the log, some lines mentioned in #5, but one "new" hit:
2176[249e1b0]: ImapThreadMainLoop entering [this=25dd008]
2176[249e1b0]: 25dd008:SERVERBLABLA:NA:ProcessCurrentURL: entering
2176[249e1b0]: 25dd008:SERVERBLABLA:NA:ProcessCurrentURL:imap://EMAILBLABLA@SERVERBLABLA:143/folderstatus%3E.INBOX.WICHTIG: = currentUrl
2176[249e1b0]: ReadNextLine [stream=242cce0 nb=0 needmore=1]
2176[249e1b0]: ReadNextLine [stream=242cce0 nb=0 needmore=0]
2176[249e1b0]: 25dd008:SERVERBLABLA:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 80470002
2176[249e1b0]: 25dd008:SERVERBLABLA:NA:TellThreadToDie: close socket connection
2176[249e1b0]: 25dd008:SERVERBLABLA:NA:CreateNewLineFromSocket: (null)
2176[249e1b0]: 25dd008:SERVERBLABLA:NA:ProcessCurrentURL: aborting queued urls
2176[249e1b0]: ImapThreadMainLoop leaving [this=25dd008]
i'd like to point to especially the line with the "null"-reference. i searched a bigger "no-problems-found" logfile and didn't find any null reference ... strange huh?
hth
Florian
Reporter | ||
Comment 14•19 years ago
|
||
Hi, this is me again. I'm, sorry to say, but the bug hasn't been entirely resolved for me yet. I did a log of level 3 and performed a very short session that also got temporarily "stuck". It wasn't the same mistake, but the way how Thinderbird got "stuck" was very reminiscienct of what sometimes happens during sending. Note also the lines in the log where it says "failed creating protocol instance" and "dooming url:imap://gustep12@localhost:143/fetch>UID>.INBOX.Junk>1", maybe these are insightful. Here is what I did:
- Started Thunderbird 1.5 (20051201)
- Automatically retrieved IMAP and displayed inbox o.k.
- Mouse click on the "Imap.Junk" subfolder, where junk messages are filtered to
- Thunderbird got stuck for almost one minute, with the blue bar revolving, till it said localhost timeout!
- I then clicked on the "Junk" folder again, and this time it worked. Strange.
- Exited Thunderbird, edited the log a little for privacy and brevity, and attached log.
Comment 15•19 years ago
|
||
Maybe related: 315713, 333661
Comment 16•19 years ago
|
||
I was asked to prefix bug IDs by the word 'bug' so that bugzilla is able to link them.
Bugs which maybe related to this one: bug 333661, bug 315713
Updated•18 years ago
|
QA Contact: message-compose
Comment 17•17 years ago
|
||
I still have this bug on last Thunderbird build. Version 2.0.0.12 (20080213)
I googled a lot about this and found out that a lot of people have this problem too but I never saw any solution about this. Even if the mail is really sent to the person, the fact that the mail is not stored in Sent folder could be seen as a loss of data, and a loss of data is a severe bug !
Comment 18•17 years ago
|
||
I've seen this a lot in the past, but not recently. I don't know if it was because I changed mail server, or upgraded Thunderbird, or changed some setting, or something else :-(
Fabien: if you are getting it, can you try Thunderbird 3.0a1 and see if that improves matters?
Gerv
Updated•16 years ago
|
Assignee: mscott → nobody
Comment 19•16 years ago
|
||
Fabien / others, any response to trying Thunderbird 3 Beta 2? http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
Whiteboard: closeme 2009-07-09
Comment 20•16 years ago
|
||
Close for lack of response at 2009-07-09.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•