370401 - frequently rebuilding my imap sent folder index?

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[(not reading, please use [e-mail] instead)]

frequently rebuilding my imap sent folder index?

i seem to be rebuilding the summary file for my imap sent folder (for [e-mail]) frequently.

in fact, I'm seeing this bug right now.  my sent folder has lots of messages (over 2000.)

I'm in the favorite folder view, and I click on it.  it tells me I have 18 total messages.  I click to another folder, and I click back and then I start downloading 2269 messages.

i'm using the latest 2.0 nightly on windows xp:  version 2 beta 2 (20070213)

I have seen this for at least a week or two, maybe longer?

I do have an nspr log (with imap:5, and a few other modules set, sorry for the noise)

Comment 1

[David :Bienvenu]

sure, send me the log - there are two possible causes : server has rolled uid validity, or the .msf file is corrupt...

Comment 2

[(not reading, please use [e-mail] instead)]

I've sent it to david privately (it's over 500 kb when compressed, so I can't attach it to bugzilla.)

Comment 3

[David :Bienvenu]

Your SENT folder has a UIDVALIDITY of 1. I'm not sure how Zimbra handles UIDVALIDITY. My folders have a variety of UIDVALIDITIES, including 1. You would not think that 1 would be a value that UID VALIDITY would be rolled to, but it might be some sort of reset value.

If this ever happens in a session where it wasn't the first time you selected the SENT folder, then I'd have a better chance of knowing if the UID VALIDITY had changed. 

I can look into trying to add some sort of logging when we think uid validity has changed, or we have an invalid DB.

Did you have a clean shutdown in your previous run of TB? 

Comment 4

[David :Bienvenu]

Attachment: proposed fix

Seth had somehow got an offline msg hdr in his db, with a "fake key" of 0xffffff80. Our quicksort, which was supposed to be doing an unsigned sort, wasn't, because the (v1 - v2) was overflowing the signed int result. This caused us to get confused when trying to figure out what headers to download, because we expected the keys to be sorted...

Comment 5

[David :Bienvenu]

fixed on branch and trunk. This might fix Scott's bugzilla folder issues - we'll see. Not sure if other folks are seeing similar issues.

Comment 6

[(not reading, please use [e-mail] instead)]

verified!

I have version 2 beta 2 (20070215), and it rebuilt my sent folder the first time I clicked on it, it does not keep rebuilding it.

thanks for the quick turn around on this one, david.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #5)
> fixed on branch and trunk. This might fix Scott's bugzilla folder issues -
> we'll see. Not sure if other folks are seeing similar issues.

Scott, did this fix your bz folder?

David, this is not limit to sent folders, correct?


David in comment #3:
> Your SENT folder has a UIDVALIDITY of 1. I'm not sure how Zimbra handles
> UIDVALIDITY. My folders have a variety of UIDVALIDITIES, including 1. You would
> not think that 1 would be a value that UID VALIDITY would be rolled to, but it
> might be some sort of reset value.
> 
> If this ever happens in a session where it wasn't the first time you selected
> the SENT folder, then I'd have a better chance of knowing if the UID VALIDITY
> had changed. 
> 
> I can look into trying to add some sort of logging when we think uid validity
> has changed, or we have an invalid DB.
> 
> Did you have a clean shutdown in your previous run of TB? 

David, how might not shutting down be related?

my bz folder frequently rebuilds.  multiple times per session.  currently, running trunk, TB also has a problem shutting down.  Also, it's the only imap folder I filter messages to.