Closed Bug 265553 Opened 20 years ago Closed 14 years ago

Mail disappears from pop inbox by downloading the rest of a message

Categories

(MailNews Core :: Networking: POP, defect)

Product:
MailNews Core
Component:
Networking: POP
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: corymogk, Unassigned)

References

Details

(Keywords: testcase, Whiteboard: [testcase: comment 17])

Attachments

(2 files)

MBOX with two header-only mails
3.20 KB, text/plain
Details
POP3 log file: Message gone in vain when downloading two message bodies
3.60 KB, text/plain
Details 
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.
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → General
Ever confirmed: true
Flags: blocking-aviary1.0?
*** 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
Severity: critical → 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://user@pop.hskupin.info: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.
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.
I'm not quite sure if the current direction is still about the problem Cory saw,
but I can confirm Henrik's observations with "version 0.6+ (20041020)" [we
*definitely* need more useful UA data!!!] homegrown trunk debug build (MinGW).
The following console dump starts after clicking the "download here" link of one
the bodyless mails:

WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
f:/Mozilla/mozilla/caps/src/nsScriptSecurityManager.cpp, line 1399 
 JavaScript error: , line 0: uncaught exception: Load of
pop://rtzertz@rtrthrt:110/?uidl=%60K9%21%21FZY%21%21%3D%5D8%22%21ng8%22%21 denied. 
 ++WEBSHELL == 5 
 ++DOMWINDOW == 5 
 WARNING: getting z level of unregistered window, file
f:/Mozilla/mozilla/xpfe/appshell/src/nsWindowMediator.cpp, line 636 
 WARNING: getting z level of unregistered window, file
f:/Mozilla/mozilla/xpfe/appshell/src/nsWindowMediator.cpp, line 636 
 WARNING: nsTimeoutImpl::Release() proceeding without context., file
f:/Mozilla/mozilla/dom/src/base/nsGlobalWindow.cpp, line 5116 
 --WEBSHELL == 4 
 ###!!! ASSERTION: couldn't lazily create the server 
 : 'NS_SUCCEEDED(rv)', file
f:/Mozilla/mozilla/mailnews/base/src/nsMsgAccount.cpp, line 99 
 ###!!! ASSERTION: couldn't lazily create the server 
 : 'NS_SUCCEEDED(rv)', file
f:/Mozilla/mozilla/mailnews/base/src/nsMsgAccount.cpp, line 99 
 ###!!! ASSERTION: thisServer is null: 'thisServer', file
f:/Mozilla/mozilla/mailnews/base/src/nsMsgAccountManager.cpp, line 2226 
 Begin mail message delivery. 
 Abort mail message delivery. 
 ###!!! ASSERTION: child count gone negative: 'childCount != 0 || delta > 0',
file f:/Mozilla/mozilla/mailnews/db/msgdb/src/nsMsgThread.cpp, line 981 
 ###!!! ASSERTION: child count gone to 0 or below: '(PRInt32) childCount >= 0',
file f:/Mozilla/mozilla/mailnews/db/msgdb/src/nsMsgThread.cpp, line 984 
 WARNING: NS_ENSURE_TRUE(uri) failed, file
f:/Mozilla/mozilla/mailnews/base/src/nsMessenger.cpp, line 1311 
 ************************************************************ 
 * Call to xpconnect wrapped JSObject produced this error:  * 
 [Exception... "Component returned failure code: 0x80004003
(NS_ERROR_INVALID_POINTER) [nsIMessenger.messageServiceFromURI]"  nsresult:
"0x80004003 (NS_ERR 
 OR_INVALID_POINTER)"  location: "JS frame ::
chrome://messenger/content/msgMail3PaneWindow.js :: SelectMessage :: line 1544"
 data: no] 
 ************************************************************ 
 --DOMWINDOW == 4
(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.
(In reply to comment #19)

> 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.

I reproduced the JS exception by:
  1) send myself two emails
  2) retrieve the headers
  3) using a terminal session, delete both messages on the server
  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.

I cleared my Javascript console before running the above test, and got this
single error line:

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 1441"
 data: no]
Source File: chrome://messenger/content/msgMail3PaneWindow.js
Line: 1441

It's probably rude to let this exception happen, but perfectly understandable -
the client was displaying a header, and expected to select the full message
since you just asked to download it, but instead everything got deleted because
that message didn't exist on the server, so there was nothing to select. The
message key it had is no longer valid because it was just deleted...
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.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
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
Severity: blocker → normal
OS: Windows XP → All
Hardware: PC → All
Summary: mail sporadically disappears from inbox → Mail disappears from inbox by downloading the rest of a message
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).
Severity: normal → critical
(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.
Severity: critical → normal
some possible clues:
 - bug 322710 comment 2
 - bug 362361 comment 6 (re-reported as bug 368404)
QA Contact: general
=> incomplete - last response from reporter 2005-04-06
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
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 2.0.0.14 (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...
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Version: unspecified → 2.0
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
Assignee: mscott → nobody
Status: REOPENED → NEW
Component: General → Networking: POP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.pop
Version: 2.0 → 1.8 Branch
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.
Summary: Mail disappears from inbox by downloading the rest of a message → Mail disappears from pop inbox by downloading the rest of a message
Whiteboard: [closeme 2010-12-25][testcase: comment 17]
Paul, thanks for your comments. Cory seems to be gone, but I'll give this WFM based on your feedback
Status: NEW → RESOLVED
Closed: 17 years ago → 14 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2010-12-25][testcase: comment 17] → [testcase: comment 17]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: