User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 I'm not sure how this happens but I lose a few mails every week. After reading the mail quickly and making a mental note to come back to it later, it's not there later. I cannot reproduce. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. 2. 3.
Do you see these mails inside the MBOX file? What is the X-Mozilla-Status and X-Mozilla-Status2 of these mails, if they are visible. Do you set any label or do you nothing? There is another bug 244601 which describes losing mail in Thunderbird. Is it probably related or a dupe?
It seems like a similar thing. I am only using one computer (a laptop) but am checking mail from different locations (on the net at work, dial up at home). I am only using the Inbox - no custom folders. I have now turned on my logs for both filters and junk mail. I do see the missing mail in the Inbox mail file when I look at it with a text editor. The status of one such mail is: X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000
I have my options set to not download messages larger than 50KB. So, I can see the large mail. Sometimes when I download the rest of that message it disappears. While updating 265554 I had the thought to compress my mail box and restart thunderbird - some of the mails that I know went missing are now visible again through thunderbird. So, I'm now a happier man.
Christian, do you have any idea why the mails are not shown?
Sorry, no I can't. Must be somewhere deeper in the MailDB for which I've no knowledge. The Status lines are normal, a wrong entry in the .msf could be the reason for Mozilla not to show the mail - but how has it been created? Cory, do the lost mails have any common grounds? Would be interesting if Mozilla still continues to "loose" mails in the next days.
did you try a newer .8 tbird build? e.g., http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-0.8/ this is probably a dup of a fixed bug.
I can think of two commonalities but am not 100% sure there are not exceptions: 1) the mails had attachments 2) the mails were from co-workers, all in the same mail domain "@alias.com" I'll try upgrading to a newer cut and keep an eye out for it.
Bug 261668 shows a similar behavior when fetching only headers first. Seems that we sometimes get problems after downloading the rest of a message.
Yeah, catched it with build version 0.8 (20041024) While working on another bug I searched a text with the fastsearch bar at the top. Then a message gets visible that was not shown inside my inbox since the 2nd september this year. :( I've taken a look inside my mbox and saw that there are two entries for that mail. The first one only contains the whole header but without the 'Status' line: X-Account-Key: account1 X-UIDL: 9nM"!`bc!!G^["!6ng"! X-Mozilla-Status: 0419 X-Mozilla-Status2: 00000000 [...] X-UIDL: 9nM"!`bc!!G^["!6ng"! Directly after this mbox entry the same mail has an additionally entry. Following header is visible: X-Account-Key: account1 X-UIDL: 9nM"!`bc!!G^["!6ng"! X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 [...] X-UIDL: 9nM"!`bc!!G^["!6ng"! Status: U After compacting the inbox the first first entry gets deleted and only the second one exists inside the inbox. Now this mail is visible again. I'm sure that I havn't used 'Download only headers" at this time because I only use that for testing purposes. I also set no limit to 'Download size'. Seems that we marking a downloaded mail (only headers) as deleted when retrieving the whole content. After that the second entry doesn't get processed? In set case and looking at the attachment of bug 261668 I believe it is a dupe of that one.
*** Bug 261668 has been marked as a duplicate of this bug. ***
Before some minutes I recognized the same bug but this time all my mails from the inbox were deleted. What happens: I fetched the headers of the new mails and tried to load the rest of a spam mail. After clicking the download link within the mail preview every message within this inbox was deleted! I'll try to rebuild the state of the inbox into that one before I downloaded the body of the spam mail. => Blocker
Thats really bad! I checked some things and found it. Ok, what happens... When you have enabled "Fetch headers only" only the headers will be downloaded. The mbox entries will get a status of 400. What means 'Status=RO'? This is also set for every fetched header. When I start to download the body of one mail every mail which only persist of the header gets marked as deleted within this MBOX! Mails with a body aren't affected! Following exceptions I get: Error: uncaught exception: Load of pop://email@example.com:110/?uidl=K%22%5B%22%212-C%22%21B3Y%22%21e%3B%40%22%21 denied. Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMessenger.messageServiceFromURI]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: SelectMessage :: line 1581" data: no] Source File: chrome://messenger/content/msgMail3PaneWindow.js Line: 1581 Scott, David, this bug should be fixed as soon as possible because this could result in dataloss when the user compact this folder. Why we get the first exception? Is this the cause why all other header only mails are marked as deleted?
Cory, currently I'm not sure if this is the problem why you started this bug. Do you use the feature "Fetch headers only"? If not this bug moved in a completelly other direction. :/ In that case we should update the summary and you should open a new bug.
After further testing I recognized that only HTML mails are affected. Plaintext mails without a body won't be deleted.
CC'ing Howard who added only-header-fetching.
Well, with my 20041002 build of Mozilla I don't see any problem like this, and I awlays use the "Fetch Headers Only" feature. I tested by sending myself two plaintext emails, and then fetching only one of them - the other header remained in my Inbox, as expected, and I could fetch that successfully on a later pass. Then I sent myself two HTML emails and did the same thing, and again, nothing unexpected got deleted. A more detailed description of how to reproduce the problem is needed.
Created attachment 163407 [details] MBOX with two header-only mails I created a simple testcase which should be help to easily reproduce this bug. Following steps are neccessary: 1. Copy 'testcase' into a folder of any account 2. Start Thunderbird and open the folder (you have to do it twice before you see any mail inside - surely another bug) 3. Open one message (not bugzilla mail which is fully downloaded) 4. Click 'here' to download the rest of the message 5. Result: All header-only mails are deleted within this MBOX This also happens for mails which still laying on the server! Open the JS console to see the exception I already mentioned.
(In reply to comment #17) > Created an attachment (id=163407) > MBOX with two header-only mails > > I created a simple testcase which should be help to easily reproduce this bug. > Following steps are neccessary: Unfortunately this test case doesn't prove anything; when the full body of a header-only email is missing from the server then the local header is deleted. There was a bit of discussion of this on bug 185184 and David and I agreed that this is the desired behavior. So far the only problem I've had with recent builds is that headers get downloaded twice if a pop3 download session is terminated due to a TCP failure. That is, I do a Get Messages, get a bunch of headers, and go thru my usual routine of deleting Junk and then selecting the remainder for full download. If the full download pass terminates uncleanly, a subsequent Get Messages pass will re-download all the headers, including all the Junk headers I already deleted. In other words, it's quite the opposite of this problem - I never see data loss, but I do see bogus data duplication... (The connection loss is due to a flaky wireless setup in a RF noisy environment, and it happens quite often. I haven't filed a bug report on it yet because it appears to only happen in this case, and never happens on my wired connection.) > This also happens for mails which still laying on the server! Open the JS > console to see the exception I already mentioned. Of course it should not be trashing messages that are still on the server, but the only way to really duplicate this test is with an actual account on a pop3 server. I don't know about the JS exception, I'll see if I can reproduce that here.
Re comment #20: > 4) use the "Click Here" link to download a message > > at this point, both headers disappear - and that is exactly the intended > behavior. When somebody deletes the message by some other mechanism, the > headers are removed the next time the pop client talks to the pop server > and discovers they are gone. This is definitely *not* expected behaviour. If I click upon a link to download *one* mail, I certainly don't expect *any* other mail to be deleted. And if the message I clicked to download is not present anymore, I'd at least expect a (disengageable) warning...
(In reply to comment #21) > If I click upon a link to download *one* mail, I certainly don't expect *any* > other mail to be deleted. I can't test right now. But are all header-only messages removed locally even if their full counterpart is still on the server? Or really only those headers without? > And if the message I clicked to download is not present anymore, I'd at least > expect a (disengageable) warning... I can't see the use of a header-only mail without any chance (except replaying a backup on the server) of getting the full message. I guess the chance to get the code changed increases if you can name a use for such a mail.
>> If I click upon a link to download *one* mail, I certainly don't expect *any* >> other mail to be deleted. > > I can't test right now. But are all header-only messages removed locally even > if their full counterpart is still on the server? Or really only those headers > without? AFAICT only those without server counterpart are deleted. "My" problem is that trying to download *one* specific but missing mail does result in deleting *all* other bodyless mails. I do not, however, see any use in keeping bodyless mail fragments in general. I just find the silent deletion somewhat irritating.
(In reply to comment #23) > AFAICT only those without server counterpart are deleted. Ok, I tested again and I can agree with you. I don't know what's happen but now it works. > I do not, however, see any use in keeping bodyless mail fragments in general. > I just find the silent deletion somewhat irritating. Sure, IMO only the selected bodyless mail should be deleted with the information why it is done. The user has to be notified when such an action is started. Otherwise he won't understand why the deletion is done. Please provide an information and only delete the selected header-only mail. Btw. I will create a new bug for the original problem of the OP later.
(In reply to comment #24) > > I do not, however, see any use in keeping bodyless mail fragments in general. > > I just find the silent deletion somewhat irritating. > > Sure, IMO only the selected bodyless mail should be deleted with the information > why it is done. The user has to be notified when such an action is started. > Otherwise he won't understand why the deletion is done. Please provide an > information and only delete the selected header-only mail. > Btw. I will create a new bug for the original problem of the OP later. Part of the motivation behind this work was to make POP3 behave more like IMAP. I don't believe the IMAP client warns you when it synchronizes a mail folder and messages have been removed on the server by some other action. The question in my mind now is, why is the message missing on the server - who removed it? Usually, in my case, I removed it myself, so I don't need any warning anyway. I just want synchronization to be done, silently and automatically, and so that's what the code does. If messages disappear from your server mailbox on a frequent basis, in the normal course of events, such a warning would just get irritating over time. So if someone decides to add this warning, they should make a toggle to enable/disable it.
Yes, it does look like this is going in a different direction because I don't download just the headers. I did try a newer cut but noticed the problem is still there.
Does this problem still occur after Thunderbird 1?
(In reply to comment #27) > Does this problem still occur after Thunderbird 1? Hi, I hope I'm writting this in the correct place. I'm using Thunderbird version 1.0 (20041206) on Windows XP. I am having the same disappearing emails problem. They are definitely there because the little counter in the bottom right shows "Unread:0 | Total:12" etc., and when I do a search for emails in the particular problem folder the emails suddenly appear. At the moment I deal with it by searching the folder and moving the files to another folder, but I thought I should let you know about the problem. Incidentally, the emails do appear in my in-box when they are marked as unread, but the next time I open the folder they aren't there in the window where they should be. I have a vague feeling it might have started when I was toggling the group sort view, but I'm not sure. After the folder gets this problem it doesn't help by changing the sorting view. This problem has occurred in my in-box and in another local folder. I use a three window configuration. I use two email accounts (one is Gmail and the other a POP account - the problem seems to occur with both). Both download to a local "special account" whatever tat is. I don't fetch headers only, and I leave messages on the Server. It's not a desperate problem, if dealt with as I described above, but it's a bit of a hassle. Hope you can help. Mozilla rocks.
Ryantokyo, take a look inside this mbox and tell us the MozillaStatus of the non-visible messages. An explanation you can find here: http://www.eyrich-net.org/mozilla/X-Mozilla-Status.html Are the states correct? If yes, can you use this mbox in another profile to test if the messages are visible there? If you can reproduce it, so you have a mbox which you can upload as attachment?
I have the same problem using Tbird 1.0! I have been noticing that sometimes, messages suddenly appear in my inbox, that I haven't seen before (and I'm not talking about recieving from pop3 server...) The mozilla status of such a message: X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Now this is VERY annoying and because of this I was only able to read an important message after half a month (that's when it suddenly appeared), and who knows how many other important messages I lost, or am not seeing... Thunderbird is acting quite strangely anyway, here's what it does: I've used the mozilla suite before thunderbird and had set my mail locations to a different place, than the default TBird couldn't import my mail folder's correctly, so I had to copy them myself This may have nothing to do with it, who knows... Anyway, I had a huge inbox in one of my folders (few thousand messages, NO global inbox) And tbird kept displaying uncorrect red/unread message numbers, and the funny thing was, this numbers kept changing (sometimes as if it were counting in real time), sometimes growing, sometimes decreasing. Whenever the numbers where changing I just couldn't read/move/delete any message in that inbox, I had to wait, until it stopped like a roulette wheel. Sometimes even when the number isn't changing, I cannot access that inbox, it doesn't show the contents for quite a long time, in which the cursor turns into the wait image. This waiting may last for a minute or so, and after the loading stops, and my inbox's contents appear, is the point where some dissapeared messages may appear. Sometimes a neverbefore seen totally empty (no from, no subject no body) message appears, and I'm always afraid deleting that message deletes a good message from my mail file. All other inboxes were working correctly After all this I deleted more than half of that inbox, compacted folder several times and everything seemed to have resolved. But a few days ago it started happening again. As if there were some magic message count number, above which TBird gets drunk Now I get neverbeforeseen messages again, and I have to wait a minute about every five minutes, because Tbird is doing something with my inbox Does Mozilla suite's mail client suffer from this too? Because I am in desperate need of a mail client that doesn't hide my mail, and I haven't found a Thunderbird export function yet. The problem is I am losing faith in Tbird, I don't know if I delete a message I don't lose something else too, etc.
I have compacted my folders a day ago, and am browsing and deleting my emails now About every 10-20 emails I go up (sorted by date) Thunderbird starts loading as mentioned above and I cannot delete/read/whatever any email in my inbox. If I click away on a different folder and click back on the inbox, the message list is blank and TBird is still loading. After it stops loading, with big probability some hidden messages appear (it seems they are always unread messages, but am not sure) in the newly appearing message list (that is btw scrolled into a different position than I left it) That means every 5 minutes I get a few new messages I have never seen before. I am constantly crossing my fingers, that I don't get an SOS one... Can anyone help me?
Sorry for this machine gun like posting, but I mentioned an empty message appearing sometimes: It seems that TBird show duplicates of some messages and when I delete one of the duplicates, the other turns into this empty message Cheers, John
is it possible that you have mail filters that try to move mail to a folder that doesn't exist?
(In reply to comment #33) > is it possible that you have mail filters that try to move mail to a folder that > doesn't exist? David, in such a case no already read mail should be moved automatically instead he has to manually start the message filter. When I read the reporters initial statement it is another issue as bug 273778. Cory, please give us some more information.
Sorry - not sure what else I can tell you. I can't recall seeing it happen in the last few months. I'm now on v1.0.
(In reply to comment #35) > Sorry - not sure what else I can tell you. I can't recall seeing it happen in > the last few months. I'm now on v1.0. Just tell us if you used a message filter after reading the mails or does it happen anytime without your action?
When it happened, it happened to mail that was in my Inbox - no filters had been applied or were in the process of being applied. As I recall, it was messages that were large and I needed to download the rest of the message. When I download the rest of a message, I often see a duplicate of the mail appear. When the download completes, the duplicate disappears.
(In reply to comment #37) > applied or were in the process of being applied. As I recall, it was messages > that were large and I needed to download the rest of the message. When I > download the rest of a message, I often see a duplicate of the mail appear. When > the download completes, the duplicate disappears. Cory, it's by design. When you download the rest of a large message a duplicated entry is created inside the MBOX. After the whole message is downloaded the preloaded one is deleted automatically. So you the this phantom entry. I dislike that behavior because everybody thinks messages are gone. We shouldn't delete the partly messages visually. David, is there a way to update the threadpane after the download is finished and the preloaded message is removed? So no flicker will be appearing. The same method we could also use by header only messages.
Setting back to normal because it is not a dataloss bug. OS/HW => ALL
Well, Thunderbird really did it to me this time. I updated to 1.0.2 last night because 1.0 was crashing frequently on me while sending mail. This morning while downloading my new mail, my entire inbox was nuked (~1000 mails).
(In reply to comment #40) > Well, Thunderbird really did it to me this time. I updated to 1.0.2 last night > because 1.0 was crashing frequently on me while sending mail. This morning while > downloading my new mail, my entire inbox was nuked (~1000 mails). Cory, sorry for lateness. Have you backuped your MBOX files? Were this mails unvisible within the UI but still existent in the MBOX file? If that happens again also look at the status of the mails and tell us. We need more information to get closer to the problem.
(In reply to comment #40) > Well, Thunderbird really did it to me this time. I updated to 1.0.2 last > night because 1.0 was crashing frequently on me while sending mail. This > morning while downloading my new mail, my entire inbox was nuked (~1000 > mails). Cory, I'm sorry this happened, but you provide no evidence that this happened due to downloading message bodies for messages that were previously headers-only. I don't think you should have reset the severity of this bug due to that problem. Vandalising a bug, no matter how frustrated you are, just makes things all the more difficult for everyone trying to fix things. Further, you said in comment 35 that you hadn't seen this bug in a while. I have one POP account configured for headers-only download and as far as I know I haven't experienced this bug. If other people are still experiencing a problem with messages disappearing other than by server-sync (that is, they weren't deleted from the server by a different client), I'm curious to know if the new-for-2.0 feature "rebuild index" (in the folder's Properties dialog) forces the missing message to be seen. It seems there are a number of duplicates for this bug.
=> incomplete - last response from reporter 2005-04-06
It´s true: thunderbird eats my web.de e-mails (they're really gone when I don't use the option "leave message on server" with my web.de freemail account): - using a web.de freemail account - using the option "do not download messages larger than XX kB" (5kB is good for reproducing) - immediately downloading the rest of all truncated messages without waiting for the POP3 poll time limit to expire (web.de freemail accounts: 15min) RESULT: DATALOSS (the first message is being retrieved correctly, all others are gone / they disappear completely) using thunderbird 22.214.171.124 (nothing changed since 1.0.3 :-( ) reproducible: always googlemail.com does not have a POP3 poll time limit (any more); I could not reproduce this bug with googlemail.com.
Paul, would it be possible for you to run a test again and use the logging feature? You can find all the necessary information here: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop Just give it a try with some test messages and please attach the POP3 log file to that bug. That would be really helpful! We need such information to be able to fix the issue. Thanks! Lets re-open the bug...
Created attachment 327288 [details] POP3 log file: Message gone in vain when downloading two message bodies The log file shows what happens when retrieving the message bodies after downloading the message headers only. Result: after message body download the message is gone (I took a look at the compressed inbox file: the message is realy gone physically) Do I have do upload the log file for each of the following bugs????? Duplicates of this bug: bug 118432, bug 225199, bug 275594, bug 322710, bug 337950, bug 362361, bug 368404, bug 265553
Finally it seems to be fixed (or did WEB.DE fix it ... ?). With TB 3.0.1 my web.de messages don´t disappear any more when retrieving the rest of an truncated message using a WEB.DE account. Even more: I can read the header-only messages regardles to the 15min POP3 poll time limit of web.de. Great!
can someone (or everyone) indicate this problem for them is either * gone * still exists? please update the bug :) thanks (In reply to comment #48) > Do I have do upload the log file for each of the following bugs????? > Duplicates of this bug: bug 118432, bug 225199 I've closed bug 118432. and bug 225199 might get closed. which leaves this bug.
Paul, thanks for your comments. Cory seems to be gone, but I'll give this WFM based on your feedback