+++ This bug was initially created as a clone of Bug #1143551 +++ "No need of compaction of Unix Mbox file if MaildirStore" shouldn't be canCompact=false. "Compact Folder" is currently: (A) local maail folder 1. If no X-Mozilla-Status: or X-Mozilla-Status-2:, add X-Mozilla-Status: and X-Mozilla-Status-2:, else if X-Mozilla-Keys:, add X-Mozilla-Keys:, else if there is no room to write "not-written-yet tag", expaand(add new line) to X-Mozilla-Keys:. 2. Do compaction of Unix Mbox file(shift in file, if expunged bit=on, ignore it) (B) imap mail folder 1. Send EXPUNGE 2. Do compaction of Offline-Store file which is Unix Mbox file canCompact=false shouldn't be set merely by "2. Do compaction of Unix Mbox file" is not needed. Action of "1." is needed even when MaildirStore, unless design/implementation for "1." is correctly changed. ,

[Tracking Requested - why for this release]: Tb 38 will be shipped as "MaildirStore is now not-experimental, is usable" version.

If MaildirStore, "Compact" is not suitable. Hhow about "Resync", "Reorganize" like one? (A) Local MaildirStore folder. 1. At /tmp directory 1-1. If set of X-Mozilla-Status:, X-Mozilla-Status2:, X-Mozilla-Keys: doesn't exists, add correct set of them. 1-2. If not-written-yet tag exists, write it to X-Mozilla-Keys:. If no room to add tag, expand os add new X-Mozilla-Keys: header line(s). 2. Move to /cur from /tmp 3. If file for unknown message(no msgHdr points the file) is found, remove the file. 4. If unknown Mbox.sbd is found, remove it. 5. If unknown Mbox directory is found, don't touch. 6. If unknown Mbox.msf is found, remove it. 7. Remove any file in /tmp (B) IMAP MaildirStore folder. 1. SELECT Mbox, EXPUNGE 2. SELECT a non-used Mbox, and SELECT Mbox again, uid fetch 1:* Flags 3. If file for unknown message(no msgHdr points the file) is found, remove the file. 4. If unknown Mbox.sbd is found, remove it. 5. If unknown Mbox directory is found, remove it 6. If unknown Mbox.msf is found, remove it. 7. Remove any file in /tmp If MaildirStore, /tmp directory can be utilized for easy "Undo delete" implementaation. In such case, "garbage removal" is usually needed.

I don't think it is Firefox related. You should request for tracking in Thunderbird components.

(In reply to WADA from comment #0) > (A) local maail folder > 1. If no X-Mozilla-Status: or X-Mozilla-Status-2:, add X-Mozilla-Status: > and X-Mozilla-Status-2:, > else if X-Mozilla-Keys:, add X-Mozilla-Keys:, > else if there is no room to write "not-written-yet tag", expaand(add > new line) to X-Mozilla-Keys:. If you download new mail from a POP3 account into maildir backed account, are these headers automatically added? I think they are for mbox store.

(In reply to :aceman from comment #4) > (In reply to WADA from comment #0) > > (A) local maail folder > > 1. If no X-Mozilla-Status: or X-Mozilla-Status-2:, add X-Mozilla-Status: > > and X-Mozilla-Status-2:, > > else if X-Mozilla-Keys:, add X-Mozilla-Keys:, > > else if there is no room to write "not-written-yet tag", expaand(add > > new line) to X-Mozilla-Keys:. > If you download new mail from a POP3 account into maildir backed account, > are these headers automatically added? I think they are for mbox store. ??? These headers are written by Tb even when copied from imap folder to local mail folder, regardless of msgStore type of BerkleyStore/MaildirStore. "No X-Mozilla-Status:/Status2:" is for "msgStore file copied by user", and "No X-Mozilla-Keys:" is for "msgFolder file created by Tb who didn't know X-Mozilla-Keys:". If no these 3 headers, X-Mozilla-Status:/Status2: is added by first Compact, and X-Mozilla-Keys: is added by second Compact. This is current mplementation in local msgStore of BerkleyStore. "No room in X-Mozilla-Keys:" can occur if user added many tags to a mail. Initial length of X-Mozilla-Keys: is approximately 100 bytes.

I'm going to leave the esr38 tracking flag set, but we won't block tb 38.0 on this.