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.
Summary: Clear the m_keyArray between compacting of multiple folders → Clear the m_keyArray between compacting of multiple folders in nsFolderCompactState
I have filed this bug mainly because I want to get it into branch.
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?
I added the nsbranch, but please check this into the trunk so we can get testing on this.
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.
This affect local folders as well. I will already be checking in these changes on trunk as part of bug 17204.
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.
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.
Whiteboard: have fix → [PDT+]have fix
Whiteboard: [PDT+]have fix → [PDT+]have fix, ready to checkin as soon as the branch opens
fix checked on branch
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]have fix, ready to checkin as soon as the branch opens → [PDT+]have fix,
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.
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
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.
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
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
verified with build 20020322 on win, linux and mac
You need to log in before you can comment on or make changes to this bug.