Closed Bug 414723 Opened 17 years ago Closed 15 years ago

Duplicate messages appearing in list, and some messages not appearing (IMAP)

Categories

(MailNews Core :: Database, defect, P2)

Product:
MailNews Core
Component:
Database
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.0b3

People

(Reporter: kr512, Assigned: Bienvenu)

References

Details

(Keywords: dataloss, qawanted)

Attachments

(2 files, 2 obsolete files)

INBOX and INBOX.msf before and after index rebuild
(deleted), application/x-gzip
Details
cumulative fix
(deleted), patch
standard8
: review+
neil
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Thunderbird 2.0.0.9

This has happened multiple times now:  The same message appears twice in my inbox (inbox on IMAP server, not local inbox).  Also some messages don't appear in my inbox, but if I do a Search, the Search does find the message and says it is in the inbox but then if I go to the inbox it definitely does not appear in the list.

I know this is a bug because if I use "Rebuild Index" on the inbox folder, the duplicates disappear, and the messages failing to appear then appear.  "Rebuild Index" fixes the problem... until it happens again some time later.

I am using IMAP, and I am keeping the messages on the IMAP server so that I can access them from 2 different computers (both using Thunderbird).   I have the Offline Messages option enabled for all folders.   This combination of IMAP and Offline Messages is probably where the bug is -- I imagine this bug doesn't occur if using POP.


Reproducible: Sometimes

Steps to Reproduce:
To reproduce this bug, I expect that you must be doing what I am:  using IMAP and leaving the messages on the server (NOT downloading them to your local inbox folder).  i.e. the bug occurs with the inbox folder on the IMAP server, and probably not with the local inbox folder.   Also, I have the Offline Messages thing enabled for all folders, that is probably also required to reproduce this bug.
Actual Results:  
Messages appearing twice in the list in inbox, and some messages not appearing at all but discoverable via Search.


Using "Rebuild Index" solves the problem until it happens again some time later.
Version: unspecified → 2.0
Do you see the problem if you don't have "Offline Message" option enabled?
Did this NOT happen in version 1.5, using the exact same (unchanged) account settings?
I am new to Thunderbird.  2.0.0.9 is the first version I have ever used.  So I don't know if the bug exists in the 1.5 version.

I don't know if the bug still occurs when the "Offline Messages" option is disabled.  I will try disabling it and see if it occurs again.

Another thought, the bug might possibly be related to the deleting of messages.  I have Thunderbird set to move deleted to the trash folder.

I also have a number of Search Folders created.  I don't know if that is relevant.
Argh the problem happened again.  I was looking at the list of folders and for the Inbox (on the IMAP server) it said 5 unread messages, but I scrolled up and down the list of messages in the inbox several times but could find only 2 unread messages.

So I clicked "Rebuild Index" and then the other 3 unread messages re-appeared.  So the count of unread messages was correct, but 3 of the 5 unread messages were not appearing in the list!!!  (until I clicked Rebuild)

If mail number is changed on IMAP server, phenomenon you described can occur.
 1. mail-1 == N1, and fetched
 2. mail-1 => N2 (changed), new mail-2 == N1(reused)
 => N2(mail-1) is fetched, then duplicated mail-1 for N1 and N2
 => new mail-2(==N1) is not newly fetched, because N1 is already fetched
 => Search can find mail-2, because searched by IMAP SEARCH command at server
 => If rebuild-index is executed, mail-1(N2) and mail-2(N1) is re-fetched

Show "Order Received" column and check number assigned to mails.
When duplicated mail is observed, different number in "Order Received" column? Or same number?
Assignee: nobody → bugmil.ebirol
I have the same problem on a setup similar to Marcus'.

The duplicated mails have the same number in the "Order Received" column.

I also have another symptom. Sometimes when deleting or moving messages, an empty line is shown in the mails box, which cannot be deleted, (But rebuild index removes it) and some messages are hidden. If some of them are new the folder is marked as having new messages, but they are not shown in the list.
I too have seen the empty/blank line that Jacob describes, that is removed when "Rebuild Index" is used.  And yes I also have seen the folder being marked as having unread messages, but I cannot see the unread messages until I use "Rebuild Index".
confirming this bug on 2.0.0.14 on Linux (Ubuntu 8.04). Same thing - IMAP folder, some messages duplicated, others "hidden" - order received is the same on the two duplicates. I have also experienced the same blank lines when deleting messages.

Also had the inbox showing that there was 1 new message in the folder pane on the side, but not in the messages pane (the new message was actually there when accessing the same account using a webmail client, but I could not reach this message in thunderbird.

if it sheds any light, the "hidden" new message that was new but could not be navigated to in the inbox did go straight to its appropriate saved-search folder, and did have the right title and body. Viewing it in that folder remoed the (1) new message status in of the inbox in the folder pane (because this WAS the new message) but the message still could not be located in the inbox (could only navigate to it using a saved-search folder)
forgot to confirm that "Rebuild Index" fixes the symptom and each message has a unique "Order received" number. It does not fix the issue, as these symptoms return again (though it doesn't happen every time, thus it's difficult to isolate an easily reproducible example)
(In reply to comment #7)
When "search target folder" of a "saved search folder" is IMAP folder, option of "Seacrh Online" exists(if checked, searched by IMAP SEARCH command, else searched locally). Which option do you use? 
"Offline use" option is on for the IMAP Inbox?
When "dup'ed message & hidden message" happens on Inbox, "click other folder, then click the Inbox again" will alter situation?

If "dup'ed message & hidden message" happens on Inbox again, do next, please.
1. Keep back up of INBOX.msf under ImapMail directory under Mail directory
2. Re-build Index
3. Keep back up of refreshed INBOX.msf
4. Check content of (1) by text editor
Dup'ed data for dup'ed mail in (1)? Data for the hidden mail is found in (1)?

> When "search target folder" of a "saved search folder" is IMAP folder, option
> of "Seacrh Online" exists(if checked, searched by IMAP SEARCH command, else
> searched locally). Which option do you use? 

This particular filter was searched locally.

> "Offline use" option is on for the IMAP Inbox?

Yes. "Offline use" is on. I did do a File -> Offline -> Download/Sync Now (without actually going offline) earlier today.

> When "dup'ed message & hidden message" happens on Inbox, "click other folder,
> then click the Inbox again" will alter situation?

No, I did this several times and the dup'ed and hidden messages still stayed dup'ed and hidden, respectively.

I'll keep a lookout and do the thing you suggest the next time this happens, thanks.


(In reply to comment #10)
> This particular filter was searched locally.
> Yes. "Offline use" is on. I did do a File -> Offline -> Download/Sync Now
> (without actually going offline) earlier today.

Locally saved mail data can have relation to problem. Please keep back up of file of INBOX(no file extension. downloaded mail data when "Download/Sync Now". "saved search folder" possibly searches this file in your case.) in addition to INBOX.msf(mail DB) when problem occurs again.

To Marcus(bug opener), Jacob Kjeldahl, Paul Ivanov:  

Does your IMAP server support IDLE command?
Do you enable "Use IDLE support if the server supports IDLE command" option?
What value do you set in "check for new message every NN minutes"?
> Does your IMAP server support IDLE command?

I tried looking around but could not figure this out from the docs (calmail.berkeley.edu)

> Do you enable "Use IDLE support if the server supports IDLE command" option?

Yes

> What value do you set in "check for new message every NN minutes"?
every 10 minutes
(In reply to comment #13)
> > Does your IMAP server support IDLE command?
> I tried looking around but could not figure this out from the docs (calmail.berkeley.edu)

Get IMAP protocol log(NSPR log) for "Start TB, click the IMAP account, terminate Tb". If log for IDLE is seen, it's the evidence that your IMAP sever supports IDLE.

(In reply to comment #13)
> > What value do you set in "check for new message every NN minutes"?
> every 10 minutes

Silly question to avoid misleading to wrong problem analysis steps.
  Is option of "check for new message every 10 minutes" enabled?

Bug 193325 is a report of "many duplicated mails" upon IMAP with slow dial up connection, when "check for new message every *1* minutes"(too short interval for slow connection).
In Screen shot attached to Bug 193325 Comment #11, you can see phenomenon of "almost all mails are dup'ed".
Very old Bug 219251 seems to be similar issue to Bug 193325.

Bug 193325 sounds to be following issue;
 1. Mail download process is invoked by "check for new message every" setting,
    and FETCH is requested and FETCH command itself is probably completed,
    but "set status as 'not new mail'" is not done yet.
 2. Before completion of all processes of step 1, second download process is
    invoked by "check for new message every *1* minutes" setting.
    Then FETCH command for the mail is requested again, and duplicate entry for
    same mail is produced in mail DB.

Bug 379039 seems to be "hidden mail" case upon similar situation.
> Bug 379039 Some random messages not showing in Inbox IMAP folder.

Scenario like following is suspected when this bug.
  0. High-watermark==N. Largest downloaded UID==P
  1. New mail(s) arrive at IMAP server
  2. Download processes by IDLE is invoked,
     but all processes for download is not completed yet.
     2-1. FETCH for mail(UID=Q, Q>=P+1) (Save as <N+1>th mail).
          "\Seen is set by FETCH or not" depends on environment.
     2-2. Set High-watermark to <N+1>
     2-3. "STATUS flag \Seen" if required
     2-4. Repeat 2-1 to 2-3 for all new mails, increasing UID, High-watermark
 (2-X. New mail(s) arrive at IMAP server additionnaly)
  3. Download process by "check for new message every 10 minutes" is invoked,
     before completion of download by IDLE.
     And execute same actions as step 2. to download mails,
     based on incomplete status of step 2 due to the inturruption.
  4. Inturrpted step 2. is re-started, and remaing actions are executed
     based on mixture of status when step 2 was invoked and status when step 3
     was completed.

  ==>  Number of dup'ed mails & hidden mails depends on ;
       - Number of new mails arrives at step 1 (and 2-X).
       - Whether \Seen is set on FETCH or not
       - At where actions of step 2. is interrupted by invoking of 3.
(In reply to comment #14)
> (In reply to comment #13)
> > > Does your IMAP server support IDLE command?
> Get IMAP protocol log(NSPR log) for "Start TB, click the IMAP account,
> terminate Tb". If log for IDLE is seen, it's the evidence that your IMAP sever
> supports IDLE.
> 
Server supports IDLE.

CreateNewLineFromSocket:  CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID ACL RIGHTS=kxte QUOTA NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED

(In reply to comment #15)
> (In reply to comment #13)
> > > What value do you set in "check for new message every NN minutes"?
> > every 10 minutes
> 
> Silly question to avoid misleading to wrong problem analysis steps.
>   Is option of "check for new message every 10 minutes" enabled?

Yep, it is enabled.

> Bug 193325 is a report of "many duplicated mails" upon IMAP with slow dial up
> connection, when "check for new message every *1* minutes"(too short interval
> for slow connection).

Could intermittent wifi connectivity be the culprit? Connection is fast when enabled, but when there is no connection thunderbird is still left in "online" mode (and gives errors about not being able to find mail server, etc)

> 
> Bug 379039 seems to be "hidden mail" case upon similar situation.
> > Bug 379039 Some random messages not showing in Inbox IMAP folder.

Yes, certainly looks very similar (if not duplicate) to this situation.

> Scenario like following is suspected when this bug.
sorry, i did not follow the rest of this, but hopefully someone else will.

(In reply to comment #16)
> > Bug 193325 is a report of "many duplicated mails" (snip)
> Could intermittent wifi connectivity be the culprit?

I don't think so. I think culprit is "execution of timer-pop download before completion of previous download", although connection error can produce duplicate mail phenomenon upon any of POP3, IMAP, and SMTP. I saw a bug which explicitly refers to "download before completion of previous download" in bugs for "duplicate mail problem", but I couldn't recall bug number. (too many bugs for dup'ed mails)
Adding IMAP in bug summary, for ease of search.
Summary: Duplicate messages appearing in list, and some messages not appearing → Duplicate messages appearing in list, and some messages not appearing (IMAP)
Flags: wanted-thunderbird3.0a2+
Flags: wanted-thunderbird3+
Confirming based on comments as well as flags being granted.
Status: UNCONFIRMED → NEW
Ever confirmed: true
contains "bug414723" folder with INBOX and INBOX.msf in "beforerebuild" and "afterrebuild" subfolders. Hope I cleaned out Also contains README which contains the following:

Here is an example (before and after rebuilding the index) of bug 41423.

The message from ldoe@university.edu with Subject: "Cleaning of Staff Lounge Frig 6/13)" was duplicated (listed twice) in the Inbox, and the message from <team@votenader.org>  Subject: "Nader and the NBA" was hidden (not listed at all).

Note: there were no other messages from either of these two addresses in the Inbox at the time.

In particular: 
the message from <ldoe@university.edu> Subject: "Metal table in breezeway" and 
the message from <team@votenader.org> Subject: "Foregone Conclusion"

along with other emails from other addresses were all already moved or deleted from the Inbox (and were no longer listed there)
(In reply to comment #20)
> INBOX and INBOX.msf before and after index rebuild

> Content of bug414723\beforerebuild\INBOX.msf
> Line-63: (57F=20080611164056.A70C724831@mailman03.highwire.org)(582=7634)(5A4
> Line-64:    =2ef31)(599=71d7)(59A=4b0)(59C=2bdf4)(585
> Line-65:    ="Jott Networks" <notify@jott.com>)(586
> Line-66:    =Jott June Newsletter - Jott Feeds, Great Press, and more)(587
> Line-67:    =2040987648.32050@jott.com)(589=UTF-8)(58A=22db)(59B=2bdd4)(59E=22c3)
> Line-68:  (59F=6b)(59D=80)(5A1=2e0b)(58E=Linda doe <ldoe@university.edu>)
> Line-69:  (58F=opt-everyone@lists.university.edu)(590
> Line-70:    =Cleaning of Staff Lounge Frig 6/13)(591
> Line-71:    =6.1.1.1.2.20080611105756.01d83820@mail.university.edu)(593=ea5)
> Line-72:  (5A0=2e097)(5A2=e9a)(5A3=5e)(5B0=36128)(5A8
> Line-73:    =The Nader Team  <team@votenader.org>)(5A9=Nader and the NBA)(5AA
> Line-74:    =198C282645745C380C2EC2FEC817653FAB23253098D5DA7E@contact.votenader.org)
> Line-75:  (5AC=2740)(5AF=36108)(5B1=26e2)(5B2=b1)>

(5A1=2e0b) in Line-68 is culprit?

"xyz" in "(xyz=pqrstu)" looks to be sequence number in hexa-decimal.
"(5A0=2e097)(5A2=e9a)(5A3=5e)" looks to be data for (5A8=The Nader Team  <team@votenader.org>), which is the hidden/last mail. 
And, (5A1=2e0b) in Line-68 looks to be data for (58E=Linda doe <ldoe@university.edu>), which is duped mail.
If sequence number, (5A4=2ef31) in Line-63/Line-64 for (585="Jott Networks" <notify@jott.com>) may be a culprit.
Changing to Core/Networking:IMAP.
Component: General → Networking: IMAP
Product: Thunderbird → Core
Version: 2.0 → 1.8 Branch
... and proper QA.
QA Contact: general → networking.imap
I have been able to capture another occurrence of this bug. Let me know if I should post another pair of INBOX+INBOX.msf before and after the index rebuild (and if I should include a screenshot of before and after).

This time a new message was hidden (as in comment #3 and comment #7). Inbox claimed to have 1 new message, but no new messages were showing inside of it and there was one duplicate message. Rebuilding the index got rid of the duplicate and revealed the hidden message.

Not sure if it matters but both the hidden and the duplicate message are part of separate search folders. In comment #20, the duplicate message was part of a search folder.
Flags: wanted-thunderbird3.0a2+
Priority: -- → P2
This is effectively dataloss, since if the user doesn't know to rebuild their folder, they've essentially lost these messages forever.  Upgrading severity and adding dataloss keyword.

Adding qawanted in the hopes that we can get reproducible test-case on trunk.  If such a thing does happen, please nominate to block Thunderbird 3.
Severity: major → critical
Keywords: dataloss, qawanted
Target Milestone: --- → mozilla1.9.1
Given that the failure mode is really bad here, and since there's forensic data here, I think we have to block on at least looking at that forensic data.
Flags: blocking-thunderbird3+
Whiteboard: [needs dev investigation]
taking - I'm not sure how useful the .msf files are here, since the important question is "how did the bad data get into the .msf file?". For that, a protocol log is probably more useful but I'm sure this bug is really hard to catch in the act. I'll poke around the .msf files, though. Logically, we must be writing the same hdr info for two different uids into the .msf file, which probably means that we must be getting confused about what the current msg uid is when parsing headers.
Assignee: bugmil.ebirol → bienvenu
Version: 1.8 Branch → Trunk
Product: Core → MailNews Core
Attached patch try to catch this in the act, and potential fix (obsolete) (deleted) — — Splinter Review 
I just had this happen to me, so I dug around in the debugger and the code to try to see what was going on. I found that we had a thread with the wrong message in it, i.e., the msg thought its thread id was X, but it was in the thread with id X -1. I've added some assertions and warnings to try to catch this in the act. In the process, I found situations where we were creating new thread objects in the mork db, but getting back existing thread objects with stale data in them, so I added some code to make sure we clear out all the columns for the thread row and the meta row when creating new threads. I think that situation arose when we deleted a message and undid the delete, though I'm not positive about it. I'm going to run with this and see if it helps.

For the record, the imap log for the message that had the issue showed us fetching the headers, then the preview text, then I think the offline store peek, and then the message body for display (I might have that backwards). The urls got queued up one after the other, which may have had something to do with the problem.
(In reply to comment #30)
> i.e., the msg thought its thread id was X, but it was in the thread with id X -1.

It sounds for me that phenomenon/problem is an variation of "thread unsafe IMAP code" issues. Is it right?
no, I don't think so - the imap code only touches the db on the single ui thread, and only ever runs a single url against a folder at one time.
Attached patch try to cleanup confused threads (obsolete) (deleted) — — Splinter Review 
this is an attempt to fix the confused threads - I'll run with this for a while and then ask for review. I don't really have a test case for this...
Comment on attachment 359669 [details] [diff] [review]
try to catch this in the act, and potential fix

this part was checked in in an other bug:

+  {
     (*pnewThread)->SetThreadKey(threadId);
+     m_cachedThread = *pnewThread;
+     m_cachedThreadId = threadId;
+  }


the rest is still a candidate for landing.
Paul and Marcus can you reproduce this bug easily ? If so would you be willing to test a special build and see if the problems persist with that specific build ?
Target Milestone: mozilla1.9.1 → Thunderbird 3.0rc1
Moving to b4 - I'd really like to figure this out for b3, though.
Assignee: bienvenu → nobody
Status: NEW → ASSIGNED
Component: Networking: IMAP → Database
OS: Windows XP → All
QA Contact: networking.imap → database
Hardware: x86 → All
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.0b4
Assignee: nobody → bienvenu
Attached patch cumulative fix (deleted) — — Splinter Review 
I'm going to run with this a while - it does fix the duplicates for me (though you may have to load the folder twice to see the fix, depending on where we were in the view creating process), but I'm going to try to see why we get into this situation in the first place.
Attachment #359669 - Attachment is obsolete: true
Attachment #359867 - Attachment is obsolete: true
Attachment #380182 - Flags: superreview?(neil)
Attachment #380182 - Flags: review?(bugzilla)
Comment on attachment 380182 [details] [diff] [review]
cumulative fix

this patch helps a lot with the duplicate/missing messages, which I've been seeing semi-regularly with imap.

The first part is if we're creating a new thread, but find an existing threadRow w/ that id, make sure we clear out its contents so we don't have any cruft left over. 

The second part is to try to repair msgs that have one thread id but are actually in a different thread.
Attachment #380182 - Flags: superreview?(neil) → superreview+
To David Bienvenu:

This kind of issue is very hard to resolve, because user including me can't reproduce problem by himeself, and because no developer usually can see the problem(you are an  very rare exception). Do you have any plan to enhance assertion or new NSPR logging for catching cause of this bug's problem?
(In my past work for problem analysis of troubles at customer of a computer-hard & OS/middle-ware/application-software vendor, trap code is used for problem analysis in many cases.)
I've tried to add assertions to catch this bug happening, but it's been very elusive.
Attachment #380182 - Flags: review?(bugzilla) → review+
fix checked in - I changed an NS_ERROR to an NS_WARNING, first, however.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [needs dev investigation]
(In reply to comment #43)
> fix checked in - I changed an NS_ERROR to an NS_WARNING, first, however.

I can still duplicate this problem at will.

I have an IMAP account that has several search folders (bad tripwire reports, good tripwire reports).  As I mark the messages read in the saved search folders, then move to the real folder, the logwatch message is always gone but there is still a (1) next to the folder indicating there's an unread message.

This occurs every time -- using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090605 Lightning/1.0pre Shredder/3.0b3pre, on an IMAP server that supports IDLE:  

* CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH

If there's anything more I can do to help for this one, I'd be happy to.
Ray, once you're in this state, if you do a quick search using the widget in the upper right hand corner of the window, does it turn up the missing message?

Are these saved searches have just the inbox as the scope? I'm not convinced you're seeing the same problem. I know there are sometimes unrelated problems adjusting the counts on folders when messages are changed from different folders.
(In reply to comment #45)
> Ray, once you're in this state, if you do a quick search using the widget in
> the upper right hand corner of the window, does it turn up the missing
> message?

Yes, it sure does!  And when clearing the search, the message disappears.  The message also reappears if I rebuild the folder index.  Another interesting note is it's /always/ the logwatch report.

> Are these saved searches have just the inbox as the scope? 

No.  I have a "Servers" folder with 35 folders in that.  The Saved searches start at "Servers" and recursively search.

> I'm not convinced
> you're seeing the same problem. I know there are sometimes unrelated problems
> adjusting the counts on folders when messages are changed from different
> folders.
Ray, can you email me the .msf file of the real folder once you're in the state where quick search shows you the message but clearing the search does not, along with the subject of the message? Does the logwatch report always have the same subject and/or message-id?
(In reply to comment #47)
> Ray, can you email me the .msf file of the real folder once you're in the state
> where quick search shows you the message but clearing the search does not,
> along with the subject of the message? 

Mail is inbound, along with a couple of PNG's showing the issue.

More information:  After I search and find the message, clearing the search hides the message again, but if I change folders and come back, the message is now visible in the folder.

>Does the logwatch report always have the same subject and/or message-id?

No.  The subject is identical, but the message id's are different.
the patch I checked in for this bug should make it so clicking away from the folder and back, even w/o doing the quick search, should repair the threading such that the missing message re-appears. Are you seeing that?

Thx for the .msf files - I'll look at them, and see if I can reproduce the problem with the saved searches. Now that I think of it, I was seeing this problem more on a machine where I read my incoming mail in a saved search.
(In reply to comment #49)
> the patch I checked in for this bug should make it so clicking away from the
> folder and back, even w/o doing the quick search, should repair the threading
> such that the missing message re-appears. Are you seeing that?

Yes, when go back and forth twice.

Steps to get message to appear sans searching:

Click on folder -- no message
Click on different folder, click back on folder -- still no message
Click on different folder, click back on folder -- message appears.

Getting closer!

Thanks!
And I can still reproduce it (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090605 Lightning/1.0pre Shredder/3.0b3pre)
Omar, does the problem fix itself when you leave the folder and come back?

I was only able to repair the problem once I had a .msf file w/ the problem. I haven't been recreate the original mis-threading though I'm trying with the steps Ray gave.
I usually use All Folders view and I have to switch to Smart Folders view and click on different folder to fix it. In the meantime Tb crashes (bug 492571)
Target Milestone: Thunderbird 3.0b4 → Thunderbird 3.0b3
I still see duplicate messages on last night's Shredder (2009-06-11 3.0b3pre). It only happens in my Inbox for one of my accounts. This Inbox is the only folder for which I have saved searches defined. The searches are stored in the Local Folders part of the account tree. Visiting those searches gives the correct result and, when I return to the INBOX, the problem is no longer seen. Rebuilding the index in the INBOX causes it to reappear - i.e. the index rebuilding process gives an incorrect result. I have not yet determined whether the problem only occurs for messages which are caught by the terms of one or more of the searches, but that may well be so.

Do let me know if I should file a new bug.

Gerv
Depends on: 501392
No longer blocks: 569065
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: