365858 - tags lost on drag&drop from the IMAP (without tag support) to Local-folder (copy works)

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Günter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: version 2 beta 1 (20070103)

If I added a TAG to a msg while stored on IMAP folder, this TAG will be lost with moving to a Local folder.

Reproducible: Always

Steps to Reproduce:
1.select IMAP folder
2.tag a message (eg. "Later")
3.move that with D&D to a folder located in yr "Local" folder
4. check the TAG
Actual Results:  
will loose the TAG at the local folder

Comment 1

[Günter]

Attachment: after logon, a IMAP-msg was TAGed and moved top local store

Comment 2

[David :Bienvenu]

this works for me, but I'm doing it on a server that stores the tags on the server, and you're doing it on a server that doesn't seem to allow storing of the tags on the server...I'll have to try it later on a server that doesn't store tags...

Comment 3

[Günter]

@David
you wrote "you're doing it on a server that doesn't seem to allow storing of
the tags on the server."
Think that's not the case. If the server does not store the TAG, why holds the "message" the TAG with de-connecting & logging in once more? Because the msg does not store the tag locally ... the server should be the one ...

Also note the following behavior: 
--> with D&D the tagged msg over to Local store it's LOOSING the tag, 
--> ***BUT*** with COPYING to Local store it will HOLD the tag
(just recognized this behaviour ;))

Comment 4

[Günter]

Sorry,  think have mixed up the headerline! Let me correct:

This situation description is right:

--> with copy by D&D the tagged msg over to Local store it's LOOSING the tag, 
 ***BUT*** 
--> with COPYING that same msg to Local store, it will HOLD the tag

Comment 5

[David :Bienvenu]

Günter, if the server doesn't support storing tags, we store the tags in the local .msf file for the folder.

Drag+Drop is the same as copy, internally. 

Comment 6

[Günter]

David, also I have mixed the situations up a little ... sorry for that, with my both IMAP servers (web.de and 1und1.de) it's the same situation:
1. they "hold" the added TAGs also with unlogging & a new login [for that you said it's stored in .msf] -- OK for that.
2. there is a difference with 
a\\ drag&drop from the IMAP-folder down to Local-folder  and
b\\ copy that IMAP-msg to the Local-folder

With b\\ the TAG is there in the LOCAL-folder, but NOT with a\\
... that's the problem.

First I only recognized the situation with a\\ and only accidentally I notice it's different with "Copy from IMAP to Local".

Hope this clarifies the situation

Comment 7

[Magnus Melin [:mkmelin]]

Updating summary.

Comment 8

[Günter]

Sorry Magnus!!!!
Do you mean MY IMAP server don't support TAG??
How to make that for sure?
As described with my last posting with point 1. I say it holds the TAG. David said if the server does not support TAGs, they are stored to .msf. 
Now: how can I check my servers if they store the TAGs or NOT? 
Whatever the situation is with storing TAGs or not: there is a difference between "D&D" and "Copy"

Comment 9

[David :Bienvenu]

From your protocol log:

* OK [PERMANENTFLAGS (\Deleted \Seen \Answered)]

If it supported tags, it would have \* at the end of that line.

There's no difference w.r.t. tags between move/copy and drag drop.

Comment 10

[Günter]

New TB update just arrived & installed:
TB version 2 beta 1 (20070104)

Did this fixed the "bug"?! Or did I some errors / mishandling before?? 
Don't know ... but an intensive test with mgs status of read/unread, with move and d&d didn't lost the TAGs anymore!
Whatever, if I made a mistake, please forgive ... finally it works, that's the important point. 
Thanks for your patient.
Günter  

Comment 11

[David :Bienvenu]

The key to recreate this, it seems, is to drag drop an unread message (or perhaps a message you haven't read in the current session) into a local folder w/o reading the message first.

Comment 12

[David :Bienvenu]

Attachment: proposed fix

The problem was that in some situations, we were deleting the message header before we got a chance to copy the properties to the local msg hdr. So I removed the early delete; we still delete the header later on in the process...I tried some tests, and we still seem to delete the headers correctly in other situations, but I will let this bake on the trunk a little.

Comment 14

[David :Bienvenu]

this bug would also affect the junk score of messages drag dropped to local folders...

Comment 15

[Scott MacGregor]

I wonder if this patch would also fix this issue:

http://forums.mozillazine.org/viewtopic.php?p=2663613#2663613

I was able to reproduce that on the branch and the trunk. The trick is to have an imap filter moving the message to a local folder. 

Comment 16

[Scott MacGregor]

(In reply to comment #15)
> I wonder if this patch would also fix this issue:
> 
> http://forums.mozillazine.org/viewtopic.php?p=2663613#2663613
> 
> I was able to reproduce that on the branch and the trunk. The trick is to have
> an imap filter moving the message to a local folder. 
> 

I was able to still reproduce this problem with the patch. I filed Bug 366508 for this issue since it sounds different.

Comment 17

[David :Bienvenu]

fixed on trunk and branch.

Comment 18

[Marcia Knous [:marcia]]

verified fixed on the 1.8 branch using the tbird cand build, version 2.0.0.0 (20070326). I verified on Win Vista. I tagged a few unread messages from my Zimbra IMAP account and dragged and dropped them to my Local Folder, and the tags were preserved. Adding branch verified keyword.