If you do GetMsg() stop and then again GetMsg() you end up losing messages

VERIFIED FIXED in mozilla0.9

Status

P1
normal
VERIFIED FIXED
18 years ago
10 years ago

People

(Reporter: naving, Assigned: naving)

Tracking

Trunk
mozilla0.9
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta1+])

Attachments

(4 attachments)

(Assignee)

Description

18 years ago
Reproducible on win 2001030904 and linux 2001030913.

Expected results: should not lose messages
Actual results: loss of messages
(Assignee)

Comment 1

18 years ago
nominating because there is dataloss
Keywords: nsbeta1

Comment 2

18 years ago
You may want to provide a few more details for Sheela so she knows what is
needed to reproduce the problem.
QA Contact: esther → sheelar
(Assignee)

Comment 3

18 years ago
The background info is in bug 67799
(Assignee)

Comment 4

18 years ago
Created attachment 27623 [details] [diff] [review]
proposed fix

Comment 5

18 years ago
please explain the logic behind the fix.
(Assignee)

Comment 6

18 years ago
When you hit stop then you try to commit the current state by removing 
the last uidl entry in the struct newuidl. Removing last entry is not
enough because it so happens that even before a msg has been fully 
downloaded and written to the disk we start processing the next msg. 
So we end up have two entries more in newuidl structure. Therefore 
remove these two uidl entries from newuidl and then save the state in
popstate.dat

cc bienvenu

Comment 7

18 years ago
So I think that would be worth a comment in the code. Also, what if, for some
reason, there's only one extra entry there (e.g., you only have one message to
download and interrupt the download of that msg) - shouldn't we check for that
in the code?

Comment 8

18 years ago
marking nsbeta1+
Priority: -- → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 9

18 years ago
Created attachment 27852 [details] [diff] [review]
better fix

Comment 10

18 years ago
r=bienvenu
(Assignee)

Comment 11

18 years ago
I noticed that IncorporateComplete was getting called twice for each message
being downloaded. To enusre that complete is called only once, made changes 
to the last patch. We need to do so to avoid publishing the header twice in
some cases. I found one such case, where message size was 66kb and message 
downloading was interrupted by "Stop".

Keywords: patch, review
(Assignee)

Comment 12

18 years ago
Created attachment 27933 [details] [diff] [review]
revised patch
(Assignee)

Comment 13

18 years ago
Sorry, ignore the last patch dated 03/16/01 14:12. 
(Assignee)

Comment 14

18 years ago
Created attachment 27934 [details] [diff] [review]
correct revised patch
(Assignee)

Comment 15

18 years ago
David, I am assuming r= on the last patch here.
(Assignee)

Comment 16

18 years ago
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

18 years ago
Please verify this only for leave messages on the server (X).

Updated

18 years ago
Depends on: 74471

Comment 18

18 years ago
Unable to verify this bug due to bug 74471. See bug 74471 for details

Updated

18 years ago
No longer depends on: 74471

Comment 19

18 years ago
verified, 
2001-04-04-12win98
2001-04-04-14linux
2001-04-04-08mac
clicking get mssg stop and get mssg does not result in losing message.
Preference for pop was Leave messages on the server when I verified this bug.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.