Tags stored incorrectly when message moved from remote imap/pop to local folder



12 years ago
8 years ago


(Reporter: emoore, Assigned: Bienvenu)


(Blocks 1 bug, {dataloss})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070309 Firefox/
Build Identifier: version (20070326)

Thunderbird normally stores tags as message attributes in the remote folder if the IMAP server supports it. Otherwise it uses the .msf file. Mbox files store the tag using a X-Mozilla-Keys header, which can be used in message filters and searches if you add a custom header for it. However, if you move/copy a message from a remote folder to a local folder it always stores any tags in the .msf file, which means you can not find that tag in filters or searches. 

A common quick and dirty fix for mildly corrupted folders is to delete the .msf file. That rebuilds the .msf file from the data in the mbox file. If you do this  you will lose the tag for that message since it is not stored in the mbox file.

There is no obvious reason why the tag for a message in a mbox file should be stored differently depending upon where the message originated.

Reproducible: Always

Steps to Reproduce:
1.Create a tag for a message in a remote folder on a IMAP server that stores it as a message attribute. You could use a free account at www.fastmail.fm to do this.
2. Copy or move the tagged message to the local folders directory, or a POP account.
3. Use View -> Message Source and look for the X-Mozilla-Keys: header in the message. 
Actual Results:  
The message doesn't have a X-Mozilla-Keys: header. If you search the folders .msf file with a text editor you can find the tag. If you exit Thunderbird, delete the .msf file, and then restart Thunderbird the tag disappears. Any tags for messages created in POP accounts don't disappear.



12 years ago
Summary: Tags stored incorreectly when message moved from remote to local folder → Tags stored incorrectly when message moved from remote to local folder
Version: unspecified → 2.0

Comment 1

12 years ago
The reason is probably because the imap message doesn't get an x-mozilla-keys header added when the message is copied to the local folder. If you compact the local folder afterwards, we'll add an x-mozilla-keys header for the messages w/o the header.

But yes, we should add the x-mozilla-keys header when the imap message is added to the local folder...
Assignee: mscott → bienvenu
Ever confirmed: true
David, Would this fix all cases where local folder reindex might lose tags?  

This would partly solve bug 392704.  What about mail servers that don't support tag attributes - are they rare?
Blocks: 392704
Severity: normal → critical
Keywords: dataloss
Summary: Tags stored incorrectly when message moved from remote to local folder → Tags stored incorrectly when message moved from remote imap/pop to local folder
Duplicate of this bug: 394098


11 years ago
Duplicate of this bug: 440367

Comment 5

9 years ago
I've been frequently loosing tags.  This is getting very frustrating.  I'm sure others, like myself, cannot easily reproduce the tagging.  In my case, I tag messages for follow-up.  When I loose tags, I loose all information about what needs follow-up.  This is extremely problematic.

I use IMAP and configure the affected folders to also store mail locally.  I access the IMAP folders from different machines and also from my phone using iphone Mail.  Generally this all works but every once in a while I loose tags.  I think the problem happens when folders get in a bad state and need to be rebuilt.

I hope the fix to this bug will improve the reliability of tags.  As I noted above, loosing tagging information is a significant inconvenience.

If there is a patch or interim fix to this, I'd be quite happy to take and test it.  I don't have a clean repro (other than to delete an MSF file.  I've not tested but maybe corrupting an MSF file is also a good repro.

Comment 6

8 years ago
bug 691770 has a fix for this.
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 691770
You need to log in before you can comment on or make changes to this bug.