GNOME Bugzilla – Bug 660782
[pst-import] Missing tasks after import
Last modified: 2011-11-21 12:36:55 UTC
Trying to import an Outlook 2010 .pst. Two consistent issues: 1) After transfer Evolution doesn't show the "To" whom when a particular email was a reply; 2) No start or end dates transfer with Tasks. Brian
Trying this with a more recent Evolution version such as 3.0.3 or 3.2.0 is welcome, as the PST import has seen some fixes and improvements in the last months: http://git.gnome.org/browse/evolution/log/plugins/pst-import
(In reply to comment #0) > Trying to import an Outlook 2010 .pst. Two consistent issues: It will be helpful if you can provide sample pst files after removing confidential information so anyway can easily verify them. > 1) After transfer Evolution doesn't show the "To" whom when a particular email > was a reply; I cann't reproduce with Evolution 3.2.0 > 2) No start or end dates transfer with Tasks. I am not able to import tasks in Evolution 3.2.0
Tried to attach a sample pst. Bugzilla responded, "The file you are trying to attach is 2497 kilobytes (KB) in size. Non-patch attachments cannot be more than 1000 KB." Akhil, I'll email it to you. Also note, the problem/bug is still manifest in 3.0.3.
Created attachment 198305 [details] Sample pst sent by Brian Though i don't see 'To' missing in any message with Evolution 3.2.0, i see warnings on evolution terminal while importing this sample pst (evolution:19366): eplugin-readpst-CRITICAL **: A second message_store has been found - ignored (evolution:19366): eplugin-readpst-WARNING **: Could not create stream for file - No such file or directory (evolution:19366): eplugin-readpst-WARNING **: Creation of task failed: Cannot create calendar object: Invalid object (evolution:19366): eplugin-readpst-WARNING **: Email without body. Subject:(empty)
Created attachment 198731 [details] [review] evo patch for evolution; Got it, the pst-importer was adding tasks as appointments, thus it failed. I checked in GDB and it doesn't preserver start/end (due) times, they are not presented by the libpst in its structures for some reason, at least with mine libpst 0.6.53. This patch also adds a flexibility in the importer, it preselects all types which are found in the .pst file and user can then only deselect them.
Created commit 3c45eb1 in evo master (3.3.1+) Created commit 6ccd82f in evo gnome-3-2 (3.2.1+)
Just tested a full pst migration again. The 2 issues remain. 1. Tasks still not showing stand and due dates. 2. "Reply" mail not showing reply "To". Sorry to be the bearer of bad news.
Brian: That is about 3.2.1?
Yes. 3.2.1-1.f16 to be exact.
(In reply to comment #7) > Just tested a full pst migration again. The 2 issues remain. > > 1. Tasks still not showing stand and due dates. I think I noticed that, and realized it's not evolution's fault, the libpst doesn't provide this information, so it's nowhere to get from. > 2. "Reply" mail not showing reply "To". I'll recheck both to be sure. > Sorry to be the bearer of bad news. No problem at all, just the opposite. :)
OK, just checked, and mine libpst 0.6.53 doesn't set item->appointment->start/end members for tasks, thus the information is not available, unfortunately. With the replies I tried with your sample pst and all of them has set From/To and some also CC and BCC, and checking the procedure it reads these from transport headers, thus they should be quite accurate.
Created attachment 200005 [details] no "To" in reply posts
Thanks for the sent sample_2, 4MB is really too much for bugzilla, but works fine for me. I checked on one of these mails from your screenshot and I would like to ask, is the right address the one for Akhil, which should be shown in the To field on those messages, please? It seems to me that it should, but I want to be sure. Below is what is read by libpst to its structures, you can see that there is no recipient, only a sentto_address or file_as, which I can make pst plugin fallback to one of these, if the To address is not known neither from headers, nor from recip_address members. 1: item->subject = {is_utf8 = 1, str = 0x7fffc5d50430 "RE: evolution: possible bug"} (gdb) p *item $2 = {email = 0x7fffc40a6b50, folder = 0x0, contact = 0x7fffc53ef8c0, attach = 0x7fffc5ac2300, message_store = 0x0, extra_fields = 0x0, journal = 0x0, appointment = 0x7fffc5baea40, type = 1, ascii_type = 0x7fffc5e074f0 "IPM.Note", flags = 1, file_as = {is_utf8 = 1, str = 0x7fffc5e36240 "'lakhil@...'"}, comment = {is_utf8 = 0, str = 0x0}, body_charset = {is_utf8 = 0, str = 0x0}, body = {is_utf8 = 1, str = 0x7fffc5ac3650 "Akhil:\r\n\r\nGreetings. Quick update. Sorry to bring bad news.\r\n\r\nI was finally able to get a distro set up with 3.2.1. It's still not fully functional. :( Tasks still do not transfer start and end "...}, subject = {is_utf8 = 1, str = 0x7fffc5d50430 "RE: evolution: possible bug"}, internet_cpid = 20127, message_codepage = 0, message_size = 4812, outlook_version = {is_utf8 = 1, str = 0x7fffc5c22990 "14.0"}, record_key = {size = 106, data = 0x7fffc5e16800 ""}, predecessor_change = {size = 0, data = 0x0}, response_requested = 0, create_date = 0x7fffc5bbd190, modify_date = 0x7fffc5cbc100, private_member = 0} (gdb) p *item->email $3 = {arrival_date = 0x7fffc5e301a0, autoforward = 1, cc_address = {is_utf8 = 0, str = 0x0}, bcc_address = {is_utf8 = 0, str = 0x0}, conversation_index = {size = 27, data = 0x7fffc5e300f0 "\001̀l&\207k\311\355\270\376\070M\377\203\255\340\206Bm\330\345\004\210\070e"}, conversion_prohibited = 0, delete_after_submit = 0, delivery_report = 1, encrypted_body = {size = 0, data = 0x0}, encrypted_htmlbody = {size = 0, data = 0x0}, header = {is_utf8 = 0, str = 0x0}, htmlbody = {is_utf8 = 0, str = 0x0}, importance = 1, in_reply_to = {is_utf8 = 0, str = 0x0}, message_cc_me = 0, message_recip_me = 0, message_to_me = 0, messageid = {is_utf8 = 0, str = 0x0}, original_sensitivity = 0, original_bcc = {is_utf8 = 0, str = 0x0}, original_cc = {is_utf8 = 0, str = 0x0}, original_to = { is_utf8 = 0, str = 0x0}, outlook_recipient = {is_utf8 = 0, str = 0x0}, outlook_recipient_name = {is_utf8 = 0, str = 0x0}, outlook_recipient2 = {is_utf8 = 0, str = 0x0}, outlook_sender = {is_utf8 = 0, str = 0x7fffc5e39e50 "SMTP:BCONNOLLY@..."}, outlook_sender_name = {is_utf8 = 1, str = 0x7fffc5d504c0 "Brian Connolly"}, outlook_sender2 = {is_utf8 = 0, str = 0x7fffc5e30120 "SMTP:BCONNOLLY@..."}, priority = 1, processed_subject = {is_utf8 = 1, str = 0x7fffc5d50510 "evolution: possible bug"}, read_receipt = 1, recip_access = {is_utf8 = 0, str = 0x0}, recip_address = {is_utf8 = 0, str = 0x0}, recip2_access = {is_utf8 = 0, str = 0x0}, recip2_address = {is_utf8 = 0, str = 0x0}, reply_requested = 0, reply_to = {is_utf8 = 0, str = 0x0}, return_path_address = {is_utf8 = 0, str = 0x0}, rtf_body_char_count = 0, rtf_body_crc = 0, rtf_body_tag = {is_utf8 = 0, str = 0x0}, rtf_compressed = {size = 0, data = 0x0}, rtf_in_sync = 0, rtf_ws_prefix_count = 0, rtf_ws_trailing_count = 0, sender_access = {is_utf8 = 1, str = 0x7fffc5e39e80 "SMTP"}, sender_address = {is_utf8 = 1, str = 0x7fffc5d504e0 "bconnolly@..."}, sender2_access = {is_utf8 = 1, str = 0x7fffc5d50540 "SMTP"}, sender2_address = {is_utf8 = 1, str = 0x7fffc5e30150 "bconnolly@..."}, sensitivity = 0, sent_date = 0x7fffc5d504a0, sentmail_folder = 0x7fffc5e301c0, sentto_address = {is_utf8 = 1, str = 0x7fffc5e30180 "'lakhil@...'"}, report_text = {is_utf8 = 0, str = 0x0}, report_time = 0x0, ndr_reason_code = 0, ndr_diag_code = 0, supplementary_info = {is_utf8 = 0, str = 0x0}, ndr_status_code = 0}
Created attachment 200120 [details] [review] evo patch ][ for evolution; Fixes missing 'To' on replies. With it applied I see a To address on each mail from your sample pst file. Thanks for help with this.
Created commit 8f54931 in evo master (3.3.2+) Created commit 1c4c79f in evo gnome-3-2 (3.2.2+)
Are both the missing "tos" on replies and the task migration fixed?
To the issue with task migration... add that any/all attachments are also lost. Of course, I'm still talking about 3.2.1 on this end. I hope it's all fixed in subsequent versions. Grazie.
(In reply to comment #16) > Are both the missing "tos" on replies and the task migration fixed? As I wrote in comment #11, task's start/end(due) dates are not provided by libpst, and other members doesn't seem to provide the information either. It might be a question for libpst members. (In reply to comment #17) > To the issue with task migration... add that any/all attachments are also lost. Are we talking about attachment son tasks only or attachments in general? Anyway, could you open a new bug report for it, please? I'm not going to fix everything in pst-import plugin in one bug report. This one is fixing different things than it was reported initially already.
(In reply to comment #18) > As I wrote in comment #11, task's start/end(due) dates are not provided by > libpst, and other members doesn't seem to provide the information either. It > might be a question for libpst members. (Not sure what "members" means here.) So would that be worth a bug report in libpst's bugtracker? If yes, do you know the URL?
(In reply to comment #19) > (In reply to comment #18) > > As I wrote in comment #11, task's start/end(due) dates are not provided by > > libpst, and other members doesn't seem to provide the information either. It > > might be a question for libpst members. > > (Not sure what "members" means here.) Members/properties of the pst structure. > So would that be worth a bug report in libpst's bugtracker? Yes. > If yes, do you know the URL? No. ;)
:( Well, I think I found a workaround, i.e. don't migrate. Fixed.
(In reply to comment #19) > So would that be worth a bug report in libpst's bugtracker? > If yes, do you know the URL? So the place to file bug reports against libpst is http://alioth.debian.org/tracker/?group_id=30390 - best to summarize the request and mention this report - Brian, can you file that request and post the link here afterwards?
https://alioth.debian.org/tracker/index.php?func=detail&aid=313447&group_id=30390&atid=410982
For the record, I think the libpst project is dead. Thoughts? PS Why is this thread marked "Fixed"?
Not a thread but a bug report. It is FIXED because this bug report is about Evolution only, and everything that could be done in the Evolution codebase was FIXED. The rest needed to fix the entire behavior is NOTGNOME.
Andre, Respectfully, I might then suggest that Evolution either: 1. Announce that it is discontinuing pst import altogether as it is broken and not gonna get fixed; 2. Take over the pst project and make the necessary repairs as it is essential to adoption. With that in mind, the importance of a fully functional MS migration tool cannot be underestimated. It is by no means a small barrier to using Evolution. It is a deal breaker. The planet has far too much personal investment in Outlook to just leave it all behind. Anyway, you wanna call dysfunctional, "fixed"... okay. Kind regards, Brian
> Anyway, you wanna call dysfunctional, "fixed"... okay. Bug statuses and resolutions are explained on https://bugzilla.gnome.org/page.cgi?id=fields.html#status . We cannot fix something that's not in our codebase. GNOME Bugzilla obviously is not a bugtracker for any 3rd party project out there that is used by GNOME to not reinvent the wheel. But this is off-topic for this *Evolution* bug report - better to get in contact with the libpst maintainers if you want to push things.
Andre, Do you work for Microsoft? Seriously, I gotta tell ya, they've got to pleased with your response. Six weeks ago I reported a dysfunction w/ Evolution. After six weeks, it is now concluded with: "you cannot get there from here; it's not our fault; talk to the dead guy." A weeks ago in frustration I told you the global solution is simple, i.e. keep Outlook and forget Evolution. Fixed, indeed. Be well. Brian
Feel free to report a bug against your distribution, I'd say - maybe they can fix it and push fixes upstream. No need for speculations on my employer. :)
No. It's Evolution's problem. I'm through with it. I already have a working email client. I'll leave you with this: http://www.campaignmonitor.com/stats/email-clients/ . What percent of marketshare does Evolution have? Not being able to migrate to it is surely part of the problem.