Bugzilla

(In reply to ISHIKAWA, Chiaki from comment #23)
> But at least we have to kill the message as being deleted in the Inbox folder. That was done in the DiscardNewMessage().
>  
> > This would mean that moved messages would remain in the mbox file until the next compaction. But really I don't think that's such a bad thing.
> 
> Actually, it is a bad thing for a user with MANY mailing list subscriptions. 
> I am afraid if such message remains Inbox, I have to run compaction more frequently.

I don't think it'd be too bad. I've got a lot more confidence in the compaction code after the recent rewrite, and it can be optimised for speed - there's no reason compaction shouldn't run at the maximum read/write speed of the underlying filesystem.

Anyway, I had a better idea.
It's only an mbox issue (maildir isn't affected). There's a `deleteMessages()` method on the `nsIPluggableStore` API. the thing to do is to have a special case in the mbox store to delete the _last_ message in an mbox by just resizing the file. Nobody outside the mbox code ever needs to know about it.
The current `nsParseNewMailState::MoveIncorporatedMessage()` does it's own thing. But really it should just be calling the `nsMsgCopyService` to move messages, and that _does_ eventually call `nsIPluggableStore.deleteMessages()` to remove the local copy.

(In reply to ISHIKAWA, Chiaki from comment #23)
> But at least we have to kill the message as being deleted in the Inbox folder. That was done in the DiscardNewMessage().
>  
> > This would mean that moved messages would remain in the mbox file until the next compaction. But really I don't think that's such a bad thing.
> 
> Actually, it is a bad thing for a user with MANY mailing list subscriptions. 
> I am afraid if such message remains Inbox, I have to run compaction more frequently.

I don't think it'd be too bad. I've got a lot more confidence in the compaction code after the recent rewrite, and it can be optimised for speed - there's no reason compaction shouldn't run at the maximum read/write speed of the underlying filesystem.

Anyway, I had a better idea.
It's only an mbox issue (maildir isn't affected). There's a `deleteMessages()` method on the `nsIPluggableStore` API.
The thing to do is to have a special case in the mbox store `deleteMessages()`: if you're deleting the _last_ message in an mbox, it just resizes the file. Nobody outside the mbox code ever needs to know about it.

The current `nsParseNewMailState::MoveIncorporatedMessage()` implements it's own local-message-move. But really it should just be calling the `nsMsgCopyService` to move messages, and that _does_ eventually call `nsIPluggableStore.deleteMessages()` to remove the local copy.

If I get some time later this week I'll try and have a go at this and everything I said up in Comment #22.