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. --- This is not a fix for the aforementioned bugs, but it at least makes clear part of the problem. The XDDIRENTRYnnnnn: terms are not checked for length in the same way as XDIRECTORY terms. It isn't clear the same hashing strategy will work, as the XDDIRECTORY terms are used to create lists of child directories. It may be the best we can do is enforce a limit on the length of path elements in trees indexed by notmuch. lib/add-message.cc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/add-message.cc b/lib/add-message.cc index 485debad..0c34d318 100644 --- a/lib/add-message.cc +++ b/lib/add-message.cc @@ -529,7 +529,9 @@ notmuch_database_index_file (notmuch_database_t *notmuch, goto DONE; } - _notmuch_message_add_filename (message, filename); + ret = _notmuch_message_add_filename (message, filename); + if (ret) + goto DONE; if (is_new || is_ghost) { _notmuch_message_add_term (message, "type", "mail"); -- 2.30.2 _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org