Closed
Bug 284526
Opened 20 years ago
Closed 12 years ago
Cancelling mail download causes TB to forget about mail already downloaded via POP, downloads again
Categories
(MailNews Core :: Networking: POP, defect)
MailNews Core
Networking: POP
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: avi, Assigned: Bienvenu)
References
Details
(Whiteboard: [closeme 2012-04-25][needs retest])
Thunderbird version 1.0 (20050104)
If you specify "leave email on server for n days", and fail to connect, the next
time the email server is successfully to, all email will be downloaded.
1. Set up a POP account, and specify "leave email on server for 7 days".
2. Use account for at least that amount of time.
3. Attempt to check mail over very bad connection.
4. Since mail check jams, cancel the email check.
5. Check email over good connection.
Result: TB will forget that it already downloaded those 7 days of email, and
will start downloading them all again.
(No, I'm not bitter! Cleaning out 2000 emails was fun.)
Comment 1•20 years ago
|
||
I don't even need to specify "leave email on server for n days" to trigger this
problem. Simply disconnect the phone line (or have it happen to you because of
a bad connection) after you've "received 151 of 468 messages", and you'll get a
second copy of those 151.
It seems to me that whatever part of TB is talking to the POP server ought to
simply issue a series of "get 1st message", then "delete 1st message" commands,
rather than "get 1st", "get 2nd", ... "get 468th" followed by "delete 1st thru
468th". (Please pardon my use of pseudo-code.)
Reporter | ||
Comment 2•20 years ago
|
||
John, that's a nice idea, but it's not good enough. Check out RFC 1939 (which is
the POP3 spec).
Basically, when the client says "DELE n" to delete a mail message, that message
is only _marked_ as deleted. However, and this is the key part, unless the
client actually says "QUIT", the server's not allowed to delete the messages
that were marked for deletion. Thus, during a disconnect, the mail server keeps
all messages for a client who might have crashed. (This is the transaction vs
update state.)
The problem here is that the mail client should be smart enough to remember
which messages it's seen already. And it is! Note the "keep for n days" setting.
Surely TB remembers which emails it already has and is leaving on the server. My
bug here is that disconnecting from a server somehow causes this list of what's
already been retrieved to be lost.
I experience it because my emails that were already downloaded from 7 days ago
are re-downloaded because the record of what was already retrieved was lost. You
experience it, but on a much smaller scale.
This is a plea for any sort of workaround for this issue. I've got (for the
third time this week) about 5000 messages waiting to be re-downloaded and
re-filed. Is there some way to reset the last-message-read value? I can talk
POP, if that helps.
Assignee | ||
Comment 4•19 years ago
|
||
yes, this is extremely annoying...the problem is that cancelling causes us to
forget what messages we just downloaded. I'm going to change the
component/platform, etc, but it's pretty likely this is a dup.
Assignee: mscott → bienvenu
Component: General → Networking: POP
OS: MacOS X → All
Product: Thunderbird → Core
Hardware: Macintosh → All
Version: 1.0 → Trunk
Reporter | ||
Comment 5•19 years ago
|
||
(In reply to comment #4)
> the problem is that cancelling causes us to
> forget what messages we just downloaded.
I'm seeing that cancelling causes us to forget what messages we _ever_
downloaded. In my case, I cancelled before downloading any messages, yet I then
started getting every message that was on the server.
Assignee | ||
Comment 6•19 years ago
|
||
hmm, you could be right - I age messages off the pop3 server, so when this
happens, I don't get too many messages. We must be clearing out popstate.dat
when this happens. I'm pretty sure there's a bug out there that describes what's
happening and why it's hard to fix. I'll go look for it.
Assignee | ||
Comment 7•19 years ago
|
||
To reduce the amount of code I have to decipher, does everyone's server support
UIDL?
Avi, did you cancel after sending the password but before we started retrieving
messages, i.e., while we were listing the contents of your inbox on the server?
That could be relevant.
Reporter | ||
Comment 8•19 years ago
|
||
(In reply to comment #7)
> To reduce the amount of code I have to decipher, does everyone's server support
> UIDL?
I would imagine mine does (qmail).
> Avi, did you cancel after sending the password but before we started retrieving
> messages, i.e., while we were listing the contents of your inbox on the server?
I haven't any idea. All I know is that I was retrieving messages over my
cellphone connection and that I didn't get anywhere so I cancelled the download
attempt. I don't know where I was (in fact, how do you tell in the current UI?).
After that one time where I cleaned out 2000 emails, I switched to never leaving
messages on the server, and have been using that setting since.
FYI:
1) I *think* my server supports UIDL -- it's MS Exchange (ech).
Unfortunately, it requires a secure connection so I can't just telnet to 110 to
find out.
2) I'm pretty sure this happens to me when the network is disconnected while
it's listing the messages. That's usually a very long step in my case, since
there are always thousands of messages on the server.
3) I have it set to leave mail on the server for 4 days.
Thanks,
Rich
p.s. I did find a brute-force workaround, which is to move all Inbox messages to
a temporary folder, disable all message filters, re-download the 4000 messages,
delete all the duplicate messages (judging by the date of the last thing in my
Inbox), re-enable the filters, run filters on Inbox, and move the
temporary-Inbox messages back to Inbox.
Comment 10•17 years ago
|
||
hi guys, i here for the same bug too. Even though some 2 years have gone since this bug was reported i still am experiencing this issue.
I simply can't understand what's taking so long to fix it when the solution is so simple...(post no. 1 here)...please understand that this bug is very anoying for me as i am receiving over 3k e-mails / day and i don' t like to have 12k messages in my inbox and some 3-4 copies of each message...
If nobody can fix this one i'm willing to help with a patch or something.
Thunderbird is an excellent e-mail client (my favorite) but bugs like this make people turn their backs on us and the open-source community
Assignee | ||
Comment 11•17 years ago
|
||
Have you tried a trunk build? I've been working on this in a different bug, and I believe I've fixed it on the trunk. It hasn't made it into an official released build because of our release cycle.
ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk
See the last few patches in bug 240049
Comment 12•17 years ago
|
||
Haven't tried it yet but will let you know how it works
Thanks
Comment 13•16 years ago
|
||
This problem still seems to exist in 3.0.
A good workaround would be to allow the user to set a "batch size", where each
POP session would download and delete only the first N messages, then QUIT. My phone line has been so flaky lately that I would just set N=1 and forget about it.
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•16 years ago
|
QA Contact: networking.pop
Comment 14•14 years ago
|
||
John in comment #13:
> This problem still seems to exist in 3.0.
>
> A good workaround would be to allow the user to set a "batch size", where each
> POP session would download and delete only the first N messages, then QUIT. My
> phone line has been so flaky lately that I would just set N=1 and forget about
> it.
John do you still see this??
xref bug 352998 Mail never deleted after connection loss
Whiteboard: [needs v3.1 retest]
Comment 15•14 years ago
|
||
I upgraded from dialup to DSL in Dec 2009, and have not had the kind of disconnection that would trigger the problem since, so I don't know.
If someone using dialup still cares about this bug, would they please respond. Otherwise, maybe it's time to set this RESOLVED EXPIRED.
Comment 17•13 years ago
|
||
This seems rather abandoned. And Rich Feit's address is dead.
If anyone still see this, please speak up.
Whiteboard: [needs v3.1 retest] → [closeme 2012-04-25][needs retest]
Comment 18•12 years ago
|
||
RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•