Clear the m_keyArray between compacting of multiple folders in nsFolderCompactState

VERIFIED FIXED

Status

MailNews Core
Backend
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Navin Gupta, Assigned: Navin Gupta)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+]have fix,)

Attachments

(1 attachment)

(Assignee)

Description

17 years ago
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.
(Assignee)

Updated

17 years ago
Summary: Clear the m_keyArray between compacting of multiple folders → Clear the m_keyArray between compacting of multiple folders in nsFolderCompactState
(Assignee)

Updated

17 years ago
Whiteboard: have fix
(Assignee)

Comment 1

17 years ago
Created attachment 41153 [details] [diff] [review]
proposed fix.
(Assignee)

Comment 2

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

Comment 3

17 years ago
rs=bienvenu

Comment 4

17 years ago
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?
Keywords: nsBranch

Comment 5

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

Comment 6

17 years ago
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.
(Assignee)

Comment 7

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

Comment 8

17 years ago
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.
(Assignee)

Comment 9

17 years ago
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. 
Keywords: vtrunk

Comment 10

17 years ago
adding PDT+
Whiteboard: have fix → [PDT+]have fix
(Assignee)

Updated

17 years ago
Whiteboard: [PDT+]have fix → [PDT+]have fix, ready to checkin as soon as the branch opens
(Assignee)

Comment 11

17 years ago
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,

Comment 12

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

Updated

16 years ago
Status: RESOLVED → VERIFIED
Keywords: vtrunk

Comment 17

16 years ago
verified with build 20020322 on win, linux and mac
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.