When moving an e-mail inside thunderbird to a folder, assigned tags are removed

I have found a reproducible way to show a problem: add a second tag to a message, then try moving it between folders; only one tag remains. Another scenario (I'm not sure if this merits a separate bug report?) is to access the same account with the 2-tag message using T-bird v1.5 - one of the tags will be lost.

I'm seeing this too with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070614 Thunderbird/3.0a1pre ID:0000000000 [cairo] and a current 2.0.0.5pre nightly build on Mac OS X (Intel).

This only happens when you are moving/copying a tagged message to a folder where no index exists or when it has to be updated. In such a situation the tags get lost.

Does the server support custom keywords? Are you using one of the old five $label tags (e.g., the labels we had in 1.5) or new tags?

Activating the servers custom keywords let's this issue move away. But I don't think that the server has to support this feature. I also tried to get this working without this server setting and it works! But you have to circumvent it.

Normal copying/moving of messages around some existing IMAP folders doesn't remove the tags. This only happens for folders with no existing index file. Getting it to work is to open the newly created folder first before moving/copying the message into it. Than the tag doesn't get lost.

Also if the server uses a further index file to store custom keyword information we can enable that for servers which doesn't support this feature. What we should do is building the index file first if its not valid. And afterwards we can move/copy the tagged message. Would this be possible?

comment #4...

> What we should do is building the index file first if its not valid. And
> afterwards we can move/copy the tagged message. Would this be possible?

add dataloss keyword

i don't know that this is gone, but worth retesting with trunk build because several tag bugs have been fixed this fall

Shi in comment #1
> I have found a reproducible way to show a problem: add a second tag to a
> message, then try moving it between folders; only one tag remains. Another
> scenario (I'm not sure if this merits a separate bug report?) is to access the
> same account with the 2-tag message using T-bird v1.5 - one of the tags will be
> lost.

see bug 378973

I tried using the latest nightly trunk build (which mapped to /pub/thunderbird/nightly/latest-comm-1.9.1), and was not able to access any folders other than INBOX in my imap account; thus I am unable to test this bug. The error I encountered was an Alert dialog containing the message: "The current command did not succeed. The mail server responded:invalid mailbox name .". My imap server directory is INBOX/ and personal namespace is "INBOX." (although "" also seems to work for me in T-bird v2). I also tried blanks for imap server dir. & personal namespace, to no avail.

update: after trying blanks, when I restored imap server to INBOX and left personal namespace blank I got my folders accessible, but all listed below the Inbox (changing this back to "INBOX." or "INBOX" doesn't seem to change this behaviour any more). Also, the Account Settings dialog started not closing when I pressed the OK button; I was able to work around this problem by using the X button in the upper right corner (changes I made did seem to 'stick').

On the plus side, I was able to test this bug since my test folders (although appearing as subfolders of the Inbox) are now accessible. The second tag which formerly disappeared as a consequence of the message being moved from one folder to another (both on the server) now remains intact. Also tested successfully with 4 and 5 tags.

Another issue turned up while going through this process: it now takes about 2 seconds in the Account Settings dialog to switch from the top-level account settings pane to the Server Settings pane (I tried the others and they're not nearly as bad). Has this issue already been filed?

Yet another issue: when I installed Shredder I didn't see any option to use a different profile - it just went ahead and attached itself to my existing profile.

update: I discovered the reason I was getting subfolders in imap was that I had mistakenly named the imap server director IMAP/ instead of INBOX/ - after restoring this setting and trying Shredder again, it did manage to show the contents of folders other than the Inbox without the Alert that I saw before.

In reply to Wayne's question (sorry for the delay in my reply), copying tagged messages between folders on the server (IMAP) or from the server to a local folder does not seem to cause loss of those tags any more. However, after reading [bug 378973] I tested and found that my local tags were lost after deleting the containing folder's .msf file. Furthermore, when I look at the message source (both on the server as well as local) I do not see any X-Mozilla-Keys headers. I'd be happy to file this info under that bug, but I saw that it was closed as resolved. I'm using v3.1.5, and could not find a field showing which version fixes this issue so I have no way to tell what behaviour to expect.

Thanks!

(In reply to Shi Sherebrin from comment #10)
> In reply to Wayne's question (sorry for the delay in my reply), copying
> tagged messages between folders on the server (IMAP) or from the server to a
> local folder does not seem to cause loss of those tags any more.

for a different view, Bug 760856 - After moving local folder to IMAP folder, tags of contained mail messages are lost

> However,
> after reading [bug 378973] I tested and found that my local tags were lost
> after deleting the containing folder's .msf file. Furthermore, when I look
> at the message source (both on the server as well as local) I do not see any
> X-Mozilla-Keys headers. I'd be happy to file this info under that bug, but
> I saw that it was closed as resolved. I'm using v3.1.5, and could not find
> a field showing which version fixes this issue so I have no way to tell what
> behaviour to expect.
>
> Thanks!

Shi, we would want you to confirm this behavior using a current version, eg TB14/TB15. That said, I've seen such a bug report somewhere - can't find it ATM. :( I see only an imap example - bug 392510

I still experience this annoying problem with TB 17.0.2 on mac OSX Lion 10.7.5. Moving messages among imap folders often, though not always "hides" tags. Restarting TB, compacting destination folder or unsubscribing & resubscribing dest. folder usually reveals the destination message's tag as it should be (as was in source folder). Most testing was moving tagged message from a folder with many messages to a new folder with none or only a few messages. Behavior seen with Smartermail v8 and Tuffmail (cyrus?) servers.

Todd, the reporter, writes "I am no longer using that system. Only online now."