142703 - mail headers all reloaded and header labeling lost

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[jesse]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041711

upon opening inbox ocassionally all headers are lost and need to be reloaded
from IMAP server.  Additionally, all priority labeling information is lost in
this process.

Reproducible: Sometimes
Steps to Reproduce:
Not sure how to reproduce this exactly yet.  It seems sporadic and could be
related to server changes (however, other email software doesn't encounter this
problem).  

Expected Results:  only new headers should be loaded, old headers should be
saved locally.

Additionally, Mozilla should encode priority labeling into message headers on
the IMAP server so that priority can be determined from any node and cannot be lost.

this bug is reminicent of bug 138065 , but I'm not using L2TP.

Comment 1

[laurel]

changed assignee, cc ssu

Comment 2

[David :Bienvenu]

my guess is that your IMAP server is rolling UID validity. Is it a cyrus server?
There are some old versions of the Cyrus server (or is Courier? I can't remember
for sure) that have trouble if you use keywords, which we do for labels, that
result in the server rolling UID validity, which forces us to redownload the
headers (the IMAP RFC requires this). We do store labels on the server, if the
server supports it.

Comment 3

[jesse]

As far as I know it's a M$ exchange server.  Does exchange not allow for server
side priority labels?

Comment 4

[David :Bienvenu]

No, Exchange doesn't support user defined keywords, IIRC. It's not a real IMAP
server; it's just some imap protocol support glued on top of an Exchange MAPI
1.0 server. There's not much we can do about this.

Comment 5

[Ulf Uhrmann]

I've got a similar problem with TB 1.0 and Seamonkey 1.7.5:
Due to my config (multiple clients running on different machines at the same 
time, server locks mailbox while accessed), I get a popop "The current command 
did not succeed. The mail server responded: Could not select mailbox".
That's ok, but at next successful access to this folder (mostly inbox) the 
corresponding .msf is recreated, due to this all labels are lost.

UID's seem to be the same, so I guess it's a MailNews bug? (Or is it the server 
once again? :)

Comment 6

[Ulf Uhrmann]

Attachment: excerpt from ethereal log

Comment 7

[Mike Cowperthwaite]

A fix has been checked in for bug 235354.  Does that also address this problem?

Comment 8

[Mike Cowperthwaite]

Sorry -- I marked this one by mistake, the problem described here seems to be 
unrelated.  But, see bug 170247.

Comment 9

[David :Bienvenu]

Attachment: make sure select succeeded before processing mailbox update

I don't know if this will fix the problem (it all depends on the type of url
being run) but it should fix some potential problems.

Comment 10

[David :Bienvenu]

patch above checked in to trunk - please try tomorrow's builds, if you think you
can help test this, thx!

Comment 11

[David :Bienvenu]

I'm going to mark fixed - please re-open if this still happens.

Comment 12

[David :Bienvenu]

Attachment: proposed fix

this should fix the remaining problem. If the folder is locked at startup,
we'll issue a select, ignore the fact that it failed, and then issue the acl
commands. If those commands succeed, they'll clear the commandFailed state, and
we'll think the select succeeded. So, if the last command failed, say we didn't
issue the select, and everything should fall out.

Comment 13

[David :Bienvenu]

ok, fix checked in - please try tomorrow's build. Thx for the help, Ulf.