146558 - If "check other folders" prefs are turned on, erroneous data is returned.

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[dylang]

Here's a situation:  I have an imap tree open.  I have several folders marked as
"to check" (thanks to the fix for bug 18266).  However, if I'm reading this
folder and the timeout expires that triggers the check thread, it sometimes
"updates" the view with incorrect data (in this case, that several messages I've
read and replied to are "new" and unread).

Clicking the messages will then usually cause the thread pane to update to the
correct level.

I'm guessing that somewhere a cache isn't flagged dirty like it should be, or
that the IMAP update writebacks aren't going through properly.  But I could be
wrong :)

Comment 1

[Ere Maijala (slow)]

I've seen something similar when checking mail from two different machines. I'm
getting the same old messages (ones I've read on the first machine) marked as
unread on the other system. It feels like changes are lost if the connection is
broken. I'm using UW IMAP, which will deliberately kill the old connection if a
new one is established. Someone said that UW IMAP daemon itself might lose
changes if the connection is not terminated by the client, but I'm not sure.
Anyway, even if it's the servers fault, I think we should work around it somehow. 

Confirming and changing OS as I'm running Win2K and WinXP. I also think
"Networking: IMAP" is a more suitable category for this, right?

Comment 2

[dylang]

I'm using Cyrus IMAP, which gracefully handles multiple connections.

My situation is that the connected thread which changes messages to read doesn't
sync the data back to the server often.  In the meantime, the biff thread goes
and rechecks all the subfolders on the server and overwrites the more recent
local cache of a subfolder view.  The little message status still says "read" on
the list window, but the message(s) is(are) flagged as "new" and bolded again
due to how the biff reconciles the two message counts.

:-/  My thought is that when viewing a subfolder, you have a lock around the
data so other Mozilla threads can't overwrite it.  

Comment 3

[dylang]

Still in Moz 1.1b (2002072204) -- really easy to trigger.  Sitting there, I
review ~30 email messages across 3 subfolders.  The event trigger occurs, and
they're all full of "unread" messages -- even when I'm reading through them
(really annoying to click to one, hit n a bunch as I read through, then have
them all turn unread behind my cursor as I'm going along).

Also in newer trunk builds, but I'm not using them right now (IMAP sent folder
broken :-/).

Comment 4

[David :Bienvenu]

taking, potential fix upcoming.

Comment 5

[David :Bienvenu]

Attachment: proposed fix

this attempts to fix a race condition where we can end up in the selected state
in the same folder in two connections, when a connection has a pending select
but isn't selected in the target folder yet, and another connection request
comes along for that same folder. This has r/sr=sspitzer.

Comment 6

[David :Bienvenu]

Attachment: proposed fix

this attempts to fix a race condition where we can end up in the selected state
in the same folder in two connections, when a connection has a pending select
but isn't selected in the target folder yet, and another connection request
comes along for that same folder. This has r/sr=sspitzer.

Comment 7

[David :Bienvenu]

I believe this was fixed a while ago...I think this is a dup of another bug, and
the problem turned out to be that we were using the wrong flag state...