notmuch/lib, branch 0.32.2

lib/config: fix memory leak

2021-06-25T12:13:04Z

This commit fixes a small memory leak (per iterator restart) by actually using the talloc context intended to be blown away on restart.

lib/n_d_index_file: re-use thread-id of existing message

2021-05-22T12:08:02Z

This prevents the message document getting multiple thread-id terms when there are multiple files with the same message-id. This change shifts some thread ids, requiring adjustments to other tests.

lib/open: restore default database path of $HOME/mail

2021-05-15T11:40:05Z

Although this default worked for "notmuch config get", it didn't work most other places. Restore the previous functionality, with the wrinkle that XDG locations will shadow $HOME/mail if they exist. This fixes a bug reported by Jack Kamm in id:87eeefdc8b.fsf@gmail.com

lib/notmuch_database_reopen: reload some database metadata

2021-05-12T11:40:04Z

In some uses of reopen, new documents and threads maybe have been added, and e.g. compaction may have changed the uuid.

lib/config: expand relative paths when reading from database

2021-05-10T14:12:58Z

This makes the treatment of relative paths consistent between the database and config files.

lib/config: canonicalize paths relative to $HOME.

2021-05-10T14:08:18Z

Prior to 0.32, notmuch had the (undocumented) behaviour that it expanded a relative value of database.path with respect to $HOME. In 0.32 this was special cased for database.path but broken for database.mail_root, which causes problems for at least notmuch-new when database.path is set to a relative path. The change in T030-config.sh reflects a user visible, but hopefully harmless behaviour change; the expanded form of the paths will now be printed by notmuch config.

lib/config: remove early free in _get_email_from_passwd_file

2021-04-24T15:11:45Z

This (obvious) bug was caused by cut&pasting the code from notmuch-config.c into the library and adding on a return at the end.

compat: rename {,notmuch_}canonicalize_file_name

2021-04-24T11:07:00Z

When compat canonicalize_file_name was introduced, it was limited to C code only because it was used by C code only during that time. >From 5ec6fd4d, (lib/open: check for split configuration when creating database., 2021-02-16), lib/open.cc, which is C++, relies on the existent of canonicalize_file_name. However, we can't blindly enable canonicalize_file_name for C++ code, because different implementation has different additional signature for C++ and users can arbitrarily add -DHAVE_CANONICALIZE_FILE_NAME=0 to {C,CXX}FLAGS. Let's move our implementation into a util library. Helped-by: Tomi Ollila Signed-off-by: Đoàn Trần Công Danh

lib/n_d_index_file: check return value from _n_m_add_filename

2021-04-18T13:02:20Z

Ignoring this return value seems like a bad idea in general, and in particular it has been hiding one or more bugs related to handling long directory names.

lib: directly traverse postlists in _n_message_delete

2021-04-18T12:50:36Z

This is intended to fix the slow behaviour of "notmuch new" (and possibly "notmuch reindex") when large numbers of files are deleted. The underlying issue [1] seems to be the Xapian glass backend spending a large amount of time in db.has_positions when running queries with large-ish amounts of unflushed changes. This commit removes two uses of Xapian queries [2], and replaces them with an approximation of what Xapian would do after optimizing the queries. This avoids the calls to has_positions (which are in any case un-needed because we are only using boolean terms here). [1] Thanks to "andres" on IRC for narrowing down the performance bottleneck. [2] Thanks to Olly Betts of Xapian fame for talking me a through a fix that does not require people to update Xapian.