89189 - Clear the m_keyArray between compacting of multiple folders in nsFolderCompactState

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect)

Description

[Navin Gupta]

This needs to be done otherwise CompactAll folders for local folders would 
mess-up badly because it would try to copy the messages from wrong offsets.

Comment 1

[Navin Gupta]

Attachment: proposed fix.

Comment 2

[Navin Gupta]

I have filed this bug mainly because I want to get it into branch. 

Comment 3

[David :Bienvenu]

rs=bienvenu

Comment 4

[scottputterman]

So is what's happening now that each successive folder that gets compacted
doesn't have an empty array of keys to copy over to the new file?

Comment 5

[scottputterman]

I added the nsbranch, but please check this into the trunk so we can get testing
on this.

Comment 6

[David :Bienvenu]

what happens now is that each successive compact when doing compact all of
offline stores tries to copy all the msg keys from all the previous folders,
which causes all sorts of goofy things to happen. Most of the msg keys don't
exist in the current folder, of course, or we don't have offline bodies for them.

Comment 7

[Navin Gupta]

This affect local folders as well. I will already be checking in these
changes on trunk as part of bug 17204.

Comment 8

[scottputterman]

I know this will be a pain, but 17204 doesn't need to go in for testing pre
branch landing, but this does, so if it's possible to land this without 17204,
that would be great.

Comment 9

[Navin Gupta]

fix landed on trunk. Without this fix if you have more than 1 folders it will 
behave unpredictably because it will try to find the messages in the wrong 
offset from the 2nd folder onwards. 

However to make sure that Compact All is still working, test it for mutliple 
folders having 50-100 messages in each folder. It should compact all of them 
and to verify you can look at the disk space consumed before and after 
compaction, by each folder. 

Comment 10

[scottputterman]

adding PDT+

Comment 11

[Navin Gupta]

fix checked on branch

Comment 12

[esther]

I've been testing this with the trunk build 7-9 and am still seeing some
problems with a 2nd POP folder after compacting.  My 2nd folder is showing
behavior as mentioned in comment on 7-6, the file size increases with
compacting.  Note I have a message in that folder that gives a "Unknown Error"
after copying it into that folder.  Still investigating, not sure if this
Unknown Error message is causing the problem. 

Comment 13

[esther]

It's possible the problems I'm seeing with the POP folders is because of bug
90186 I just logged where this same behavior is seen when multiple select copy
of 500+ msgs to a new folder happens.  Still investigating

Comment 14

[esther]

Testing working around the corruption of the folder by bug 90186, this is OK on 
Windows.  Folder file size decreases and message headers match msgs displayed. 
Checking Mac and Linux now.

Comment 15

[esther]

Finished testing Mac and Linux, both worked OK. After deleting half the msgs in 
folders A & B, I compacted the folders, the file sizes decreased and the thread 
headers matched the displayed msg in the message pane.
trunkverified

Comment 16

[esther]

This was fully verified on Branch, partially verified on Trunk (windows only).  
leaving resolved,fixed and vtrunk in keywords so it can be verified more on the 
trunk

Comment 17

[esther]

verified with build 20020322 on win, linux and mac