GNOME Bugzilla – Bug 578945
[pst-import] Adapt to changes in libpst 0.6.41
Last modified: 2009-07-27 05:14:47 UTC
Corresponded with Carl Byington over upcoming changes to his libpst: "The major change is that almost all the char* fields in the mapi items (email, contact, etc) have changed to PST_STRING to properly handle code pages vs. utf8. The 64bit pst files can contain items with some strings in utf8, and other strings in the item's code-page. The PST_STRING type saves that information. For any given element, you can pst_convert_utf8() to force that element into utf8, and it will use iconv to convert the data if it is not already in utf8 format." Sounds like we have some work to do.
I made a patch for .35 but seems Carl already has made the changes needed for .36 to the plugin. Would be attaching the patch once he's done with it.
Created attachment 132675 [details] [review] compatible with 0.6.35 pst_attach_to_mem missing from libpst. Need to find an equivalent for it. maybe use pst_attach_to_file?
Created attachment 132804 [details] [review] compatible with 0.6.37 .37 has some changes required for the plugin
http://www.five-ten-sg.com/libpst/packages/libpst-0.6.37-pre.tar.gz is the pre-release tarball.
I realize libpst is still < 1.0, but does the API show signs of stabilizing any time soon? It seems to be changing awfully fast.
@Matthew Yes the changes are too frequent and many off late. What I hear from the maintainer is, he'll make sure the Evolution plugin gets all it needs and then he'll stabilize the libpst code. Review comments from the libpst maintainer for my patch. + if (attach->data.data != NULL) { + camel_mime_part_set_content (part, attach->data.data, strlen (attach->data.data), mimetype); attach->data is of type pst_binary, with fields size_t size, and char * data. The pst_binary.data is not necessarily null terminated, so strlen(attach->data.data) should be replaced by attach->data.size in all cases. + if (item->file_as.str != NULL) { + m->folder_name = foldername_to_utf8 (item->file_as.str); Any time you need a pst_string converted to utf8, it should be done via pst_convert_utf8() or pst_convert_utf8_null() depending on whether you want to preserve NULL strings. That will use the default character set of the containing item, unless the pst_string came from a unicode mapi element, in which case it is already in utf8. + if (item->email->outlook_sender_name.str != NULL && item->email->outlook_sender.str != NULL) { + camel_internet_address_add (addr, item->email->outlook_sender_name.str, item->email->outlook_sender.str); Any time you use a pst_string.str, you need to be aware that the data in that string might be in any of a variety of character sets. In most cases, you want to normalize it to utf8 before using it. In other cases, you might want to get pst_default_charset(containing item).
we are targeting patch only for master (2.27.x) or stable (2.26.x) also as we have 2.26.2 tarballs pending on May 18.
Plugin appears to be broken again when building against libpst 0.6.41.
(In reply to comment #8) > Plugin appears to be broken again when building against libpst 0.6.41. I believe Matt is on this, and tried with the patch from comment #3, thus marking it as needs-work. I wonder whether it'll has some value to re-attach here patches for each libpst release, and not rather wait for API stabilize there. Though I see Bharath talking about their willing to change API based on evo needs, thus it makes sense from this point of view.
I emailed Carl about his plans for libpst and strongly suggested he defer any further API/ABI breaks to 0.7 and keep 0.6 stable from here out. Distros can't keep up with the current rate of breakage.
Created attachment 139130 [details] [review] Compatible with libpst-0.6.41 The importer was broken on master. This works well for me. I have made the first change mentioned in the previous review, but I'll change the utf8 string handling for later. That needs more testing with the change. The attached patch should work well with the latest version
Committed to master for 2.27.5 http://git.gnome.org/cgit/evolution/commit/?id=fd66fd1800b1f32f1de9f0b19749a11e7f8377b6 Reopen the bug for any issues with this version update.