601885 - Message moved to different account acts as if in old account

Status: RESOLVED DUPLICATE of bug 327713

(Thunderbird :: Folder and Message Lists, defect)

Description

[Arthur]

(TB 3.1.6)
When moving messages from a folder in one account to another the account is preserved even though the following (default) setting is active:

mailnews.database.summary.dontPreserveOnMove account msgOffset threadParent msgThreadId statusOfset flags size numLines ProtoThreadFlags label

If I e.g. receive a message in my spam filtering account which was erroneously classified as spam and move it to the corresponding "ham" account and reply to it the settings of the spam account are applied instead of those of the ham account. There doesn't seem to be a workaround (if one doesn't count editing the mbox-file).

This once worked (at least in 2.x times).

Comment 1

[Mark Banner (:standard8)]

(In reply to comment #0)
> (TB 3.1.6)

3.1.6 hasn't been released yet, we only landed the 3.1.6pre change a few hours ago. Please be careful to quote the correct version from Help -> About (it doesn't matter too much for this report, but can be confusing at times).

Comment 2

[Arthur]

That would be 3.1.4. Sorry about that.

Comment 3

[Kent James (:rkent)]

I'm not sure if this bug is about dontPreserveOnMove, or about the symptoms beginning with "If I e.g. receive a message ..." It is possible they are related, but it is not obvious to me that they are.

dontPreserveOnMove is really a setting for extension developers, that controls whether summary database fields are preserved when a message is moved. I don't know how the "account" field is used in the message database, and I would need to check its use to see if dontPreserveOnMove is an issue here or not.

Comment 4

[Arthur]

Thanks. Yes, it's possible. But aren't the summary database fields and the TB specific X-* fields (e.g. the X-Account-Key) meant to map? When regenerating the summary db TB takes its values from those X-* fields. Or isn't this true anymore?

From what I see is that TB looks at that account field (whether in the summary db or directly in the message) and acts accordingly. I unfortunately won't have time to look closer at it.

Comment 5

[Kent James (:rkent)]

"When regenerating the summary db TB takes its values from those X-* fields. Or isn't this true anymore?"

The bug where dontPreserveOnMove was defined was part of a larger effort to ensure that when the database is regenerated for various reasons (reindex, message move, folder rename) that any fields defined in that database would be preserved if possible. That is because not all fields are or can be represented in the underlying message stores (imap only allows binary fields, mbox capacity is limited.) This particularly affected junk-related fields like junkpercent, but could apply to any field that is added to the message database for example by an extension.

When the database is regenerated, it attempts to recover different fields in different ways. Some fields are regenerated from the headers in the messages, but others are regenerated simply by copying those fields from a predecessor database. junkpercent would be an example of the latter.

So for the purposes of this bug, you really need to define the symptom that is the issue, rather than assume that somehow a faulty dontPreserveOnMove is the issue.

Comment 6

[Arthur]

Ok, adapted summary accordingly. New symptom description:

If I e.g. receive a message in my spam filtering account which was erroneously
classified as spam and move it to the corresponding "ham" account and reply to
it the settings of the spam account are applied instead of those of the ham
account.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Arthur(bug opeer), are you talking about problem of bug 327713 and/or bug 592935?

Comment 8

[Arthur]

Thanks WADA. Marking as dupe of 327713. I'm wondering whether all those related bugs actually could be fixed if dontPreserveOnMove would be (ab-)used to actually don't preserve the account info in X-Account-Key when moving messages.