User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 Mail imported from outlook don't have thunderbird headers (X-Mozilla-Status,...). So if you mark these mails as read, they come back as unread after reconstruction of msf file. Reproducible: Always Steps to Reproduce: 1.import outlook pst profile 2.mark mail imported as read 3.delete msf file for its folder Actual Results: Mail are in unread status Expected Results: Mail are in read status Have marked mail as new

If possible, it would appreciate a rebuild functionality that can add thunderbird headers after importation. In our case we have migrated about 40 Pc from Outlook to Thunderbird, and after 6 months we have imported mails in inconsistent status (X-... headers are not in the mails header).

Sorry, I omitted version of Thunderbird. The problem exist for version 1.0.3, the latest test was made with version 1.0.6 (20050716)

if you delete a message, and do a context menu compact this folder, the x-mozilla-status headers will be added as part of the compact process.

what version did you use to do the importing? I thought that bug was fixed a while ago, that import didn't added x-mozilla-status.

The last import was made with thunderbird 1.0.6 (20050716)

darn, it was fixed for Outlook Express but never Outlook. Compacting folders is the only way to get those x-mozilla-status lines into the messages. And compacting won't do anything unless at least one message is deleted.

I've tried to delete a message from folder and compacting it after deletion, this add TB headers to mail imported and resolve the problem. Do you think is a good idea to submit a bug for "compact folder" utility?

We've already got a command File | compact folders that will compact all the folders in a given account. The auto-compact feature will compact folders in all accounts (tools | options | advanced | offline and disk space - automatically compact folders when it will save xx KB. So we're unlikely to add a separate utility. We'd rather spend resources making compaction more automatic, and/or support mail formats that don't require compaction.

I haven't tested this, since Outlook refuses to register itself as the mapi client on this machine, but I'll try it on a different machine.

I,am sorry for my bad english, in comment nr 7 I don't ask you to develop a new utility for compacting folders correctly. My question is: Is a bug of actual "compact folder" functionality adding missing headers only if I delete a message from the folder? If the functionality exist, through context menu or option setting is the same, I think it must work correctly. I hope to not abuse of your patience.

similar? Bug 160027 (less active, old?) related? bug 219269

(In reply to comment #9) > Created an attachment (id=201889) [details] > possible fix for problem at import time > > I haven't tested this, since Outlook refuses to register itself as the mapi > client on this machine, but I'll try it on a different machine. @David: what were your results ? (if you remember ;) Maybe we could try it out ?

Wow, I really don't remember - if you have a setup where you can try it out, that would be great (I don't know if the patch even applies anymore)

I've applied the patch manually so hopefully the build would be a success and I will let you know about the results.

Unfortunately compilation fails: ../../../../mozilla/dist/include/xpcom\nsCRT.h(295) : warning C4005: 'FILE_ILLEG AL_CHARACTERS' : macro redefinition ../../../../mozilla/dist/include/msgbase\msgCore.h(216) : see previous d efinition of 'FILE_ILLEGAL_CHARACTERS' d:/mozilla/source/mailnews/import/outlook/src/nsOutlookMail.cpp(595) : error C20 65: 'MSG_FLAG_READ' : undeclared identifier d:/mozilla/source/mailnews/import/outlook/src/nsOutlookMail.cpp(597) : error C20 65: 'MSG_FLAG_ATTACHMENT' : undeclared identifier d:/mozilla/source/mailnews/import/outlook/src/nsOutlookMail.cpp(609) : error C38 61: 'EscapeFromSpaceLine': identifier not found d:/mozilla/source/mailnews/import/outlook/src/nsOutlookMail.cpp(611) : error C38 61: 'EscapeFromSpaceLine': identifier not found d:/mozilla/source/mailnews/import/outlook/src/nsOutlookMail.cpp(663) : error C38 61: 'EscapeFromSpaceLine': identifier not found d:/mozilla/source/mailnews/import/outlook/src/nsOutlookMail.cpp(1061) : warning C4018: '<' : signed/unsigned mismatch

ah, yes, life has moved on quite a bit since that patch. I'll see if I can't quickly get you an updated patch.

(In reply to comment #16) OK, great, the other option could be to fix bug 219269 ;)

this needs to be fixed no matter what...

> 'EscapeFromSpaceLine': identifier not found these errors are preventing successful build, though they are not related to the patch hmm ?

Are you building on the comm-central trunk? Those errors are not related to the patch. Does the patch apply cleanly?

Przemyslaw: tried to build again?

I've had some conversation with David, here is my last comment: (didn't get reply yet) patched build didn't changed anything for me imported mail from outlook does not have X-Mozilla-Status headers, after marking message as read they also do not show up and so after rebuilding index messages are reset to unread state I've tested with outlook 2003 and 2007 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20090217 Shredder/3.0b2pre

Can you use the debugger to see if the lines that the patch added are executed?

"status update": I've added printfs to the modified functions. There are no printfs from the nsOutlookMail.cpp so this means that the patched function was not executed. (waiting for other patch / patched file to play with).

Przemyslaw, are you waiting on bienvenu?

I think we don't have a patch that fixes the issue, is my recollection, and I'm more or less just guessing about what to patch, since I can't recreate the problem.

Przemyslaw do you still have a testcase? Giacomo aka the reporter seems to be gone.

This bug has been fixed by fixing Bug 207156 comment 93 (attachment 490452 [details] [diff] [review]), that fix was based on this bug's patch made by David. It is included into TB since v7 (IIRC).

David Bienvenu, as you have produced a patch here, can you confirm comment 29?

(In reply to :aceman from comment #30) > David Bienvenu, as you have produced a patch here, can you confirm comment > 29? I'll trust mike on this one.