1153720 - Stale cached count/number of messages(?): delete folder, empty trash bin, create folder with deleted folder's name, then the new folder is displayed as having messages equal to number of messages in the deleted folder, even though it is empty

Status: NEW

(Thunderbird :: Folder and Message Lists, defect)

Description

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

(I tested this both 64-bit and 32-bit linux. I am using POP3 if it matters.)


While testing C-C thunderbird for enabling buffered output to POP3 inbox (today it is not 
buffered) and making sure it does not corrupt data even multiplexed with
filtering operations and other moveing/copying of e-mail messages,
I found an annoying bug.
After a folder is deleted and trash folder is emptied to make sure the
data is gone,  if I create another folder with the name of the just deleted folder,
it is created alright, but it shows it has # of messages already (the # being the
# of messages in the deleted folder). The display is bogus.
As soon as I click on the newly created folder, the display is cleared.


Repeat-by: step 0 and step 1 are to create a folder with certain # of messages for testing purposes.

    step 0: create a new folder
    step 1: put messages to the new folder (say three messages)
    step 2: delete a folder, 
    step 3: empty the trash folder, 
    step 4: create a folder with the same name of the deleted folder's name

    step 5: (Problem)
    The newly created folder shows up in the folder pane. BUT it shows 
    the # of messages that were in the deleted folder (say, three if I put three messages in step 1.)
    This number is bogus and confusing!

    step 6: If I visit the new folder by clicking on it,
    the # of messages is cleared (as it should be since it is newly created and nothing is inside).

I think the incorrect display in step 5 is confusing, and should be corrected.

This is observed  both with the released 31.6.0 and
C-C source tree version (locally created).

My guess: it seems there is a cached information of the number messages in a folder
somewhere which should be purged when the trash folder is emptied in step 3.
But it does not get cleared and thus TB is showing a false # of messages.
Somehow it is re-computed when the folder is selected.

TIA

PS: When I submit this bugzilla entry, bugzilla suggested a few similar issues, 
one of which is below:
Bug 455047 - Delete a new message, empty the trash, TB still thinks there is new mail until you click on the trash bin (it's empty already)

Considering that "TB still thinks there is new mail" is based on the # of unread messages, 
it seems that there are some cached information about the number of UNREAD messages which needs to be cleared when trash folder is emptied, but not quite cleared.
My story above is about the total # of messages shown, but I think the unread # of messages were also bogus (cached and reflected the previously deleted message).

Comment 1

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

What is obnoxious about this issue is that
if I invoke compact folders (from the [File] menu and touch all relevant folders instead of single one),
the bogus # of messages in the newly created folder (empty) is still intact (until I visit the folder).

That is, obviously, this cached information survives the compactify operation (although I doubt
if the newly created folder and its .msf file is touched by compactify operation at all.).

Repeat-by: step 0 and step 1 are to create a folder with certain # of messages for testing purposes.

    step 0: create a new folder
    step 1: put messages to the new folder (say three messages)
    step 2: delete a folder, 
    step 3: empty the trash folder, 
    step 4: create a folder with the same name of the deleted folder's name

    step 5: (Problem)
    The newly created folder shows up in the folder pane. BUT it shows 
    the # of messages that were in the deleted folder (say, three if I put three messages in step 1.)
    This number is bogus and confusing!

    step 5.5 (Compactify)

    [File] Compact Folders ....-> The bogus # of messages is still displayed.

    step 6: If I visit the new folder by clicking on it,
    the # of messages is cleared (as it should be since it is newly created and nothing is inside).

TIA

PS: I thought there was a bug that "compact folders do not update .msf file in C-C TB generally" in C-C TB, but I think this strange behavior of bogus cached # of messages of the deleted and soon re-created folder was the culprit of this single intance of compactify not clearing the message number even if I run "compactify folders". I should re-check on this point, though.

Comment 2

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

I still see the bug in C-C TB, and I am afraid that this may cause message
corruption due to internal DB inconsistency. So I raise the issue to "Major".

To show the error clearly, I created a series of screen capture (only the relevant section is shown.)

Comment 3

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

Attachment: deleting-a-folder-part-1.png

Screen capture: part-1.

1. I created a new folder "folder-new" from scratch.
It stared as an empty folder as it should be. So far, so good.

2. I copied several messages form other folders. Four messages were unread and so
"(4)" is shown next to the folder name, folder-new.

3. Now I tried to delete this folder. First, I delete it and move it to Trans folder.

Comment 4

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

Attachment: deleting-a-folder-part-2.png

Part-2.

4. Now to totally remove/purge/eradicate "folder-new", I epmty the Trash folder.

5. As soon as I hit "yes' to delete everything in the Trash folder,
"folder-new" is gone.

Comment 5

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

Attachment: deleting-a-folder-part-3.png

Part-3

6. I re-create "folder-new" from scratch again.
I invoke "New Folder" dialog, with "folder-new" and hit "Create Folder" button

A BIG SURPRISE.

7. A freshly created "folder-new" appears.
But TB seems to still holds on to the now STALE information about the old/deleted/purged folder, and show "(4)" as # of unread messages to this
newly created "folder-new" (!?)

I think there is a chance for corruption of folders (!).

Comment 6

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

Attachment: deleting-a-folder-part-4.png

Part-4

8. As soon as I "SELECT" the folder, "folder-new", TB seems to update the
internal database finally. It no longer shows the bogus "(4)" any more, and
the message pane is empty as it should be.

But it seems there is a window of vulnerability when the bogus data is intact.
For example, comment 1 suggests the bogus data survives even compaction!?

I have a feeling that this buggy behavior can be a cause of message corruption.

TIA

Comment 7

[Wayne Mery (:wsmwk)]

Walt, can you reproduce?

(not sure why I tagged it as dataloss)

Comment 8

[WaltS48 [:walts48]]

Yes, I can reproduce without quitting Thunderbird.

If I create the folder, add some messages, delete the folder, empty trash, quit Thunderbird Daily, restart, recreate the folder with the same name, the folder is displayed as empty.

Tested using Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0a1

Comment 9

[WaltS48 [:walts48]]

There is a stale message count in the folder when reproducing the steps in Comment1.

There is no stale message count if I quit and restart after emptying trash, then recreating the folder.

Comment 10

[Wayne Mery (:wsmwk)]

Thanks for testing

Unless I misunderstand, this is a minor issue

Comment 11

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

(In reply to Wayne Mery (:wsmwk) from comment #10)
> Thanks for testing
> 
> Unless I misunderstand, this is a minor issue

Does someone an idea where to look?
(I suppose it is related to the internal DB handling.
But I wonder if someone has a more specific comment such as
"it seems the DB cache invalidating call is missing when a folder is purged here in this file.", et
c.