bug: [s]ave function adds bogus pathnames into the notmuch DB

[Selene Scriven]

Some extra info from #notmuch:

<ToyKeeper> amdragon, j4ni: Here's the bug report I sent to mutt-kz.  Perhaps it might be helpful for notmuch too?  http://pastebin.ca/2638732
<ToyKeeper> (it seems like notmuch should probably have a way to detect and remove bogus paths)
<j4ni> ToyKeeper: rather, detect and not add them in the first place!
<ToyKeeper> ... perhaps when a move or copy is detected, it should stat all the other known paths and remove anything weird?
<ToyKeeper> Or not adding them in the first place.  :)
<cworth> ToyKeeper: Yes, it's not clear where the bogus path is actually coming from. Presumably some inconsistent database state due to the unhandlend Xapian exception.
<cworth> (And then, the question is why is there a repeatable Xapian exception being hit.)
<cworth> ToyKeeper: More information here will definitely be helpful.
<j4ni> apparently a missing notmuch_database_end_atomic
<amdragon> j4ni: How does that translate into a bogus path in the database?
<ToyKeeper> cworth: I can at least say the issue was introduced sometime in the past 3 months or so.  Should be relatively easy to bisect, if nothing else...  though I'll wait for KZ to respond before I dive in much further.
<j4ni> amdragon: that I don't know, but notmuch_database_close with transaction in progress is the only way, afaict, to trigger the xapian exception in the referenced log
<j4ni> ToyKeeper: you can pass on the info that one of the bugs is in remove_filename() in mutt_notmuch.c. it does not call notmuch_database_end_atomic() on the failure path of notmuch_database_find_message_by_filename().
<j4ni> however, at that point my guess is that the bad path is already in the database
<j4ni> which could be the reason for notmuch_database_find_message_by_filename() failing


-- Selene