notmuch/lib/message-file.c, branch 0.19_rc1

lib: Start all function names in notmuch-private.h with

2014-07-13T15:25:29Z

As noted in devel/STYLE, every private library function should start with _notmuch. This patch corrects function naming that did not adhere to this style in lib/notmuch-private.h. In particular, the old function names that now begin with _notmuch are notmuch_sha1_of_file notmuch_sha1_of_string notmuch_message_file_close notmuch_message_file_get_header notmuch_message_file_open notmuch_message_get_author notmuch_message_set_author Signed-off-by: Charles Celerier

lib: resurrect support for single-message mbox files

2014-06-14T01:59:04Z

This is effectively a revert of commit 6812136bf576d894591606d9e10096719054d1f9 Author: Jani Nikula Date: Mon Mar 31 00:21:48 2014 +0300 lib: drop support for single-message mbox files The intention was to drop support for indexing new single-message mbox files (and whether that was a good idea in the first place is arguable). However this inadvertently broke support for reading headers from previously indexed single-message mbox files, which is far worse. Distinguishing between the two cases would require more code than simply bringing back support for single-message mbox files.

lib: replace the header parser with gmime

2014-04-05T15:53:04Z

The notmuch library includes a full blown message header parser. Yet the same message headers are parsed by gmime during indexing. Switch to gmime parsing completely. These are the main changes: * Gmime stops header parsing at the first invalid header, and presumes the message body starts from there. The current parser is quite liberal in accepting broken headers. The change means we will be much pickier about accepting invalid messages. * The current parser converts tabs used in header folding to spaces. Gmime preserve the tabs. Due to a broken python library used in mailman, there are plenty of mailing lists that produce headers with tabs in header folding, and we'll see plenty of tabs. (This change has been mitigated in preparatory patches.) * For pure header parsing, the current parser is likely faster than gmime, which parses the whole message rather than just the headers. Since we parse the message and its headers using gmime for indexing anyway, this avoids and extra header parsing round when adding new messages. In case of duplicate messages, we'll end up parsing the full message although just headers would be sufficient. All in all this should still speed up 'notmuch new'. * Calls to notmuch_message_get_header() may be slightly slower than previously for headers that are not indexed in the database, due to parsing of the whole message. Within the notmuch code base, notmuch reply is the only such user.

lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()

2013-09-14T17:13:43Z

As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: > Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() > *should* solve the decoding problem mentioned in the thread. This > flag should be safe to pass into g_mime_init() without any bad side > effects and my unit tests do test that code-path. The thread being referred to is [2]. [1] id:87bo56viyo.fsf@nikula.org [2] id:08cb1dcd-c5db-4e33-8b09-7730cb3d59a2@gmail.com

lib/message-file.c: use g_malloc () & g_free () in hash table values

2012-12-24T23:02:05Z

The message->headers hash table values get data returned by g_mime_utils_header_decode_text (). The pointer returned by g_mime_utils_header_decode_text is from the following line in rfc2047_decode_tokens return g_string_free (decoded, FALSE); The docs for g_string_free say Frees the memory allocated for the GString. If free_segment is TRUE it also frees the character data. If it's FALSE, the caller gains ownership of the buffer and must free it after use with g_free(). The remaining frees and allocations referencing to message->headers hash values have been changed to use g_free and g_malloc functions. This combines and completes the changes started by David Bremner.

Fix appending of Received headers

2011-06-11T00:03:14Z

We're not properly concatenating the Received headers if we parse them while requesting a header that isn't Received. this fixes notmuch-reply address detection in a bunch of situations.

lib/message-file: plug three memleaks.

2011-06-03T19:30:55Z

Signed-off-by: Jameson Graef Rollins

Make Received: header special in notmuch_message_file_get_header

2010-04-26T21:44:06Z

With this patch the Received: header becomes special in the way we treat headers - this is the only header for which we concatenate all the instances we find (instead of just returning the first one). This will be used in the From guessing code for replies as we need to be able to walk ALL of the Received: headers in a message to have a good chance to guess which mailbox this email was delivered to. Signed-off-by: Dirk Hohndel

fix notmuch_message_file_get_header

2010-04-07T01:47:28Z

fix notmuch_message_file_get_header to always return the first instance of the header you are looking for Signed-off-by: Dirk Hohndel

message_file_get_header: Use break where more clear than continue.

2009-11-18T02:37:45Z

Calling continue here worked only because we set a flag before the continue, and, check the flag at the beginning of the loop, and *then* break. It's much more clear to just break in the first place.