Closed Bug 465800 Opened 16 years ago Closed 15 years ago

Messages in an IMAP folder continue to appear after they are deleted and purged using another client

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: robert.flach, Unassigned)

References

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081105 Lightning/1.0pre Shredder/3.0b1pre

When using IMAP mail folders, Thunderbird will continue to display mail messages which have been removed from the server.  Refreshes, shutdown/restart, etc. have no affect... the messages continue to be displayed in Thunderbird until you delete them using Thunderbird.

Reproducible: Always

Steps to Reproduce:
1. View a message in an IMAP folder in Thunderbird
2.a Using a non-thunderbird mail client (such as a webmail client) delete the message from the server.  (Be sure to purge deleted messages so that it is really removed from the server and not merely marked as deleted)
2.b. OR manually delete the mail message from the server.
3.view the folder in thunderbird.  Message is still there.
3.a. click to a different folder and back.  Message is still there.
3.b. click on the message.  Message is displayed.
3.c. click send-and-receive.  Message is still there.
3.d. Close Thunderbird and Restart it.  Message is still there.
Actual Results:  
Deleted message continues to appear in Thunderbird display.

Expected Results:  
Message which has been completely purged from the server should not be displayed the next time the folder is viewed (or at a minimum after the next send-and-receive action).

I performed this test on WinXP, with the latest nightly.  I use a Qmail->Courier IMAP server setup.  However, I suspect that this problem probably applies across all OS/server setups.

This is a regression bug.  The problem does not occur on TB2.

This is my first bug report as I try to give a little something back to the TB project.  Please let me know if more info is needed.
One additional note: No error message is produced when the message is deleted from TB, despite the fact that the message didn't exist on the server to be deleted.
Version: unspecified → Trunk
Check the folder properties, is the folder set up for offline use? Does not having it set up for offline access make a difference?
Keywords: regression
Phenomenon was observed with Tb trunk on MS Win-XP SP3, using Gmail IMAP with "IDLE support=Off". The phenomenon was observed with both folder of Offline-Use=Off & folder of Offline-Use=On.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081109 Shredder/3.0b1pre

 Client-1(Tb trunk)  Client-2(Sm 1.1.12/Gmail IMAP)  Client-3(Sm 1.1.12/via Web)

 1. Copy a mail(say Mail-1) to Folder-A
    (i.e. Gmail label of "Folder-A" is added to Mail-1)
 2. View the copied mail in Folder-A
                                                     3. Remove Gmail label of
                                                        "Folder-A" from Mail-1
                                                        (== delete & expunge)
                     4. Open Folder-A
                        => Mail-1 doesn't exists
 5. Deletion of Mail-1 is not notified to Tb,
    because IDLE support=Off
 6. Open other mail folder, then re-open Folder-1
    => Mail-1 still exists. Mail-1 can be viewd.
 7. Move the Mail-1 in Folder-A to other mail folder
    (IMAP level: COPY UID to Folder-X, then UID FLAG \Deleted) 
    (I tested with "Mark as deleted" model.)
    => Following error occurs beacuse UID for the Mail-1 doesn't exist.
> The current command did not succeed. The mail server responded: No messages match. (Failure).
This error continues until "Rebuild Index" is executed.

(In reply to comment #1)
> One additional note: No error message is produced when the message is deleted from TB, 
> despite the fact that the message didn't exist on the server to be deleted.

Which "delete model" do you use?
Move to Trash? Mark as deleted? Remove immediately?
Status: UNCONFIRMED → NEW
Component: General → Networking: IMAP
Ever confirmed: true
Product: Thunderbird → Core
QA Contact: general → networking.imap
Confirmed based on Bug 466637 (same error as comment #3 after this bug).
Changed to Core/Networking:IMAP.
Severity: normal → major
OS: Windows XP → All
(In reply to comment #2)
> Check the folder properties, is the folder set up for offline use? Does not
> having it set up for offline access make a difference?

The bug occurs for me whether the folder is setup for offline use or not.

(In reply to comment #3)
> Which "delete model" do you use?
> Move to Trash? Mark as deleted? Remove immediately?

I'm using the Move to Trash delete model in firefox...  Emptying trash also did not produce an error for me.  I'll try to get around to deleting using other models and see if that produces the error message as in comment #3.
This appears to be working correctly for me in the latest nightly... Can anyone else confirm?
(In reply to comment #6)
> This appears to be working correctly for me in the latest nightly...

I'm also unable to re-produce problem with same test procedure of Comment #3, with following latest-trunk on MS Win-XP SP3.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081204 Shredder/3.0b2pre
It looks to be already WORKSFORME.
It may seem academic, but can you identify the oldest build where the problem goes away?
->WFM then
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
This was happening to me too in TB 3.0b1. I share an IMAP account with someone who sweeps it via POP3 from AppleMail. Often (though not always), after he sweeps the account, the messages would still appear to be there for me. Rebuilding the index always clears the problem, but sometimes, after a few more connects on my part, if new mail showed up in between, I might see the correct list.

I am _not_ using offline folders (the checkbox is off).

After reading this thread, I downloaded the nightly build of Shredder from last night (tagged 3.0b2-pre). At first blush, it seemed to solve the problem, but later on, it occurred again, so it's either intermittent, or sensitive to fewer use cases, or I was mistaken when I thought it worked.

Unfortunately, I have some other issues with the latest build (that I should open a separate bug report on and not cloud this issue), so I am reverting to b1 for the moment.
No longer blocks: 470602
Product: Core → MailNews Core
(In reply to comment #10)
> This was happening to me too in TB 3.0b1.

How many mails exists in mail folder after delete by other client?
I tested with non-Zero mails. Did you test with Zero mail?
Zero mail case is being processed by Bug 462880.
Depends on: 462880
I'm running 3.0b2 official, not a nightly build. My problem remains, consistently, as described in #10 above.

I check the account only via IMAP, without offline checked. Someone else regularly sweeps the account with POP3. Originally, he only used AppleMail, now he also uses an iPhone.

With AppleMail, he clears the account (meaning, the messages get deleted on the server after the successful POP operation). With the iPhone, he leaves the messages on the server.

All works fine for me in IMAP if he leaves the messages, and I see that they have been read. If he clears the messages (they get deleted on the server), then I still see them (phantoms now), until I rebuild the index under properties.

To answer the question about Zero mail above, I am not 100% sure. Here's what I "believe" from observation.

If the mailbox is truly Zero in length, then everything I said above is absolutely true, every time.

However, if it's been swept clean, then new mail comes in, before I check and rebuild the index, it's a little murkier. Usually, I will see a change in the mail list from the last time, so I realize there's been activity. On occasion, I believe that the updated mail list is still incorrect, and a rebuild of the index always fixes that problem.
Re-opening, because several problems seems to be involved in your case, some of them seems to have been resolved but others seems still remain.
  1. Comment #3 : Expunged by other, some active mails remain in mail folder
  2. Bug 462880 : Expunged by other, no active mail in mail folder
  3. Next is possibly issue of Bug 414723 / Bug 501392. 
> On occasion, I believe that the updated mail list is still incorrect,
> and a rebuild of the index always fixes that problem.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
To Hadar Pedhazur(poster of Comment #10 & Comment #12):

(In reply to Comment #12)

First of all. POP3 access(DLET/QUIT after RETR) of Web Mail affects on IMAP access of Web Mail or Web Mail access via Web Interface?
(I thought it's NO, as for Gmail, Gmail IMAP, Gmail POP3, unless user does do special setups.)

Original problem(comment #0) of this bug looks Problem 1. in Comment #13, because I couldn't reproduce problem of Comment #3 and bug opener says problem of comment #0 doen't occur any more.
Problem 2. in Comment #13 is remaining special case of of Comment #3.

> If the mailbox is truly Zero in length, then everything I said above is
absolutely true, every time.

It's Problem 2. in Comment #13(== Bug 462880), isn't it?
(In reply to comment #12)
> I'm running 3.0b2 official, not a nightly build. My problem remains, consistently, as described in #10 above.

3.0b2 is very old build. Can you reproduce your problem with Tb trunk nightly build?
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/
I have a problem which appears to be like this bug.

Messages deleted on an iPhone, or with RoundCube(webmail client) disappear on those clients but continue to appear in TB3.  This behaviour is new for me since I upgraded from TB2 to TB3.
  
The messages are not marked as deleted in any way on the TB user interface.  Messages which were deleted before being read still show up as unread.

This is a painful problem as when I return home I cannot determine which emails I have replied to during the day.
To Hadar Pedhazur(poster of Comment #10 & Comment #12):
To Stephen(poster of Comment #16):

As Robert Flach(bug opner) says in comment #6, original problem by bug opener is already WORKSFOME.
What is your evidence that your problem is same problem as original comment #0?
Please note that phenomenon of "same external symtom as bug summary" is not always same problem, as all crash of Tb is not always same problem even if "Tb crashed" is common.
Please open separate bug for your problem, after search B.M.O well, attaching sufficient data for problem analysis(e.g. IMAP log), with clear "step to reproduce".

Closing as WORKSFORME again.
Status: REOPENED → RESOLVED
Closed: 16 years ago15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.