251408 - Deleted messages are not removed from Drafts file

Status: RESOLVED INVALID

(MailNews Core :: Backend, defect)

Description

[baconputing]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707

When a message is saved as a Draft and then removed from the Drafts folder, the
message still remains within the Drafts file (in the user profile's mail
directory).  This can cause the Drafts file's size to swell up to dozens of
megabytes if users frequently save long drafts (particularly if they save the
same draft multiple times).  This behavior occurs regardless of how many times a
draft is saved, and regardless of whether or not the compose window for the
draft is ever closed.

It's not clear if this is the same issue as described by Bug 11387.  That bug
appears to deal with messages not being removed from the Drafts folder, whereas
in this case they are not removed from the Drafts file.

Reproducible: Always
Steps to Reproduce:
1. Compose a new message.
2. Save the message as a draft at least once.
3. Delete the draft by either A) sending it (so it is automatically removed from
the Drafts folder) or B) manually deleting it from the Drafts folder.

Actual Results:  
When you save the draft it appears inside of the Drafts folder and as a new
message at the end of the Drafts file.  However, when the draft is removed (as
specified in step #3 above) it is only deleted from the Drafts folder.  The
message itself still remains in the Drafts file.

Expected Results:  
When you save the draft it should appear inside both the Drafts folder and the
Drafts file itself.  When you delete the draft it should be removed from both
the Drafts folder and the Drafts file.

The text editor I was using to monitor changes to the Drafts file (TextPad 4.7.3
- http://www.textpad.com) has the ability to detect and notify the user when a
file has been modified by another application.  When saving the draft, TextPad
would notify me that the Drafts file had been modified and I could clearly see
the draft being appended to the end of the file.  When deleting the draft,
TextPad would notify me that the Drafts file had been modified, however, no
changes were evident in the file (the draft was never removed from the end of
the file).  Evidently when a draft is deleted Mozilla overwrites the Drafts file
with the exact same file.

Comment 1

[R.K.Aa.]

What happens if you compact folders?

Comment 2

[baconputing]

Hmmm, interesting.  That seemed to take care of it.  I had no idea that's what
it meant by "compacting".  I guess I had always assumed "compacting" meant
"compressing" (and, therefore, slower performance).

I looked in the "Mail & Newsgroups Preferences - Offline & Disk Space" section
of the Mozilla help file, and it doesn't give any kind of description of what
compacting does.  The most it says is that it helps to "conserve disk space".  A
text search for the word "compact" doesn't yield any results, either.  Perhaps
the help file needs to be updated?  Or am I the only one who wasn't aware of
what that feature did?

Comment 3

[R.K.Aa.]

No.. you're not the first one. See bug 137365 comment 5
Resolving as invalid since this works as designed.

If you think the compression mechanism should be described in more detailt in
the helpfile, please file a new bug.