Closed Bug 67799 Opened 22 years ago Closed 22 years ago

Hitting 'Stop' & then redownloading messages results in duplicates

Categories

(MailNews Core :: Networking: POP, defect, P2)

Product:
MailNews Core
Component:
Networking: POP
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: mmilli, Assigned: naving)

References

Details

(Whiteboard: [nsbeta1+]) 

From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (WinNT; I)
BuildID:    20010201

When retrieving mail messages after stopping the process midway ,all the 
messages are downloaded again including the ones which were downloaded 
previously.

Reproducible: Always
Steps to Reproduce:
1.Bring up the browser window
2.Open a new mail window
3.Compose a few messages ( say 5) and send it to an existing account by pressing 
the send button
4.Wait for some time and retrieve the messages by pressing the Get msg button
5.When the process of downloading the message is going on , interrupt it by 
pressing the stop button (say after the 2 message is downloaded,it should be 
noted that all the messages should not be downloaded completely)
6.now press the Get msg button again to resume the retrieval of the messages

Actual Results:  The messages downloaded earlier are downloaded again from the 
server.
that is;all the 5 messages are downloaded again.

Expected Results:  The messages downloaded once should not be downloaded again, 
only the remaining messages should be dowmnloaded.that is; in this specific 
example only the remaining 3 messages should be downloaded.
This was once bug 26770, a nsbeta2+ bug (marked fixed June last year.)
this is a pop bug.  re-assign to naving, who is our jefft-bug-owner now.
Assignee: sspitzer → naving
Component: Mail Window Front End → Networking - POP
change qa conact, cc esther
QA Contact: esther → sheelar
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: When retrieving messages after stopping midway all the msgs are downloaded again → Hitting 'Stop' & then redownloading messages results in duplicates
Confirmed
Platform:PC
OS: Linux 2.2.16
Mozilla Build: 2001021408
 Marking NEW.
*** Bug 69244 has been marked as a duplicate of this bug. ***
Blocks: 69244
uping severity and nominating this for nsbeta1.  When users are downloading
messages and if messages are huge because of attachments or what ever I see that
they would stop downloading very often and this can result with lot of duplicate
messages in the inbox.  This is not just one message that is duplicated but it
could be after downloading 20 messages and hitting stop on the 21st message and
redownloading resulting in bringing down those 20 messages back again. I would
like to see this fixed.
Severity: normal → major
Keywords: nsbeta1
The code is in place to handle this situation. I'll have to invesigate why it
doesn't work.
marking nsbeta1+
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9
I have not been able to reproduce this bug on win 2001030904 and linux 2001030913.
On the contrary, I found out that if you do GetMsg(), Stop and then again 
GetMsg(), you lose a message. My guess is that the number of messages that you 
may end up losing will depend upon the number of times you hit Stop. 
Filed bug 71666 to cover this issue.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
The above is true for mac 2001-03-09-11
I have seen this problem but now that it has miraculously disappeared.  I tried 
to reproduce with the recent builds and was unable to reproduce.Marking 
this as verified will reopen if this occurs again.
Status: RESOLVED → VERIFIED
sheela have you verified this when we don't leave messages on server( )

I guess you will get duplicates. Reopening..... 

Reopening this bug.....
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
cc server experts jgmyers, max 

I have a fix for this bug that works when all the messages are 
<= 50kb. If all messages are > 500kb the fix does not work. The "QUIT" 
command is needed to update the server state if we do not leave messages
on the server. The QUIT update the server state and removes all the 
message marked deleted which in our case would be messages downloaded 
successfully. 

I want to know how would server behave, while it is writing the message data to 
the client and it receives the quit command in the middle ?.

You really should be using the UIDL command of POP for this.  Remember the UIDLs 
of messages you have downloaded successfully in a local on-disk per-POP-server 
database.  On a reconnect, if you see a UIDL on the server that is in your local 
database, delete the message without downloading it.  If, on the other hand, a 
UIDL in your local database is not in the server then remove it from the local 
database.

The problem is that the exisiting code does UIDL only when we leave messages on 
the server. The scenario that I mentioned is also a bug in 4x. 

A good fix would have the client use UIDL regardless of the "leave mail on 
server" setting.  Aside from the decision for when to delete the message from 
the server, the logic should be the same in either case.

To answer the question being asked: sending the QUIT command while the server is 
still sending the message is technically pipelining.  The POP standard neither 
permits or prohibits pipelining.  The POP extensions document provides a way for 
a POP server to advertise when it supports pipelining.  Pipelining in the 
absense of that server advertisement is aggressive and may lead to 
interoperability problems.  Some clients provide a user preference which 
controls whether or not the client pipelines.

In any case, if you send the QUIT message while the server is writing the 
message and then close the connection before the server is done writing the 
message, almost all servers will notice the inability to write the message 
before they can notice the QUIT command.  Thus, sending the QUIT will have no 
effect.

fix checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Depends on: 74471
No longer depends on: 74471
buildid:  2001-04-02-06 win98
2001-04-02-10 mac
2001-04-02-08-linux

This seems to have been working on mac and windows. However when I hit stop 
button on linux I get a crash.  Opening a new bug for that. See bug 74471. Won't 
be able to verify this bug untill bug 74471 is fixed.  
I have to verify this bug not leaving messages on the server so disregard my 
comments from 2001-04-02 17:14 
I see that linux on build 2001-04-04-14 resulted in duplicates.  Have not 
checked on windows and mac will do so....
It works fine for me using today's debug build on linux. Please verify again.

verified on linux buildid-2001-04-19-08. Still need to verify this on mac &win98
verified on 
buildid: 2001042606 win98
buildid:  2001042605 linux
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.