| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Carl claims he must have been distracted when he wrote this...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since Xapian has a limit on the maximum length of a term, we have
to check for that before trying to add the message ID as a term.
This fixes the bug reported by Mike Hommey here:
<20091120132625.GA19246@glandium.org>
I've also constructed 20 files with a range of message ID lengths
centered around the Xapian term-length limit which I'll use to seed a
new test suite soon.
|
| |
|
|
| |
Just to be on the safe side of things.
|
| |
|
|
|
|
|
| |
If an earlier exception occurred, then it's not unexpected for the
flush to fail as well. So in that case, we'll silently catch the
exception. Otherwise, make some noise about things going wrong at the
time of flush.
|
| |
|
|
|
| |
Previously, our Xapian exception reports where identical so they
were hard to track down.
|
| |
|
|
| |
And correspondingly, READONLY to READ_ONLY.
|
| |
|
|
|
|
|
|
|
| |
We only rarely need to actually open the database for writing, but we
always create a Xapian::WritableDatabase. This has the effect of
preventing searches and like whilst updating the index.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Carl Worth <cworth@cworth.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
More fallout from _get_header now returning "" for missing headers.
The bug here is that we would no longer detect that a file is not an
email message and give up on it like we should.
And this time, I actually audited all callers to
notmuch_message_get_header, so hopefully we're done fixing this
bug over and over.
|
| |
|
|
|
| |
Thanks to Mike Hommey for doing the analysis that led to noticing that
this was missing.
|
| |
|
|
|
|
|
|
| |
There's been a fair amount of fallout from when we changed
message_file_get_header from returning NULL to returning "" for
missing headers. This is yet more fallout from that, (where we were
accepting an empty message-ID rather than generating one like we want
to).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was recently introduced in commit:
64c03ae97f2f5294c60ef25d7f41849864e6ebd3
which was adding extra checks to avoid adding a self-referencing
message.
How many times am I going to fix a dumb regression like this and say
"we really need a test suite" before I actually sit down and write the
test suite?
|
| |
|
|
|
|
|
| |
We had exposed this to the internal implementation for a short time,
(only while we had the silly code fetching In-Reply-To values from
message files instead of from the database). Make this private again
as it should be.
|
| |
|
|
|
|
| |
Maybe ths lack of this documentation is why I forgot we were actually
storing this and wrote the ugly code to fetch In-Reply-To from message
files rather than from the database.
|
| |
|
|
|
|
|
| |
Which is more consistent with the XREFERENCE prefix used in the terms
in the database. Also remove some stale documentation describing the
removal of resolved references from the database (we no longer do
this).
|
| |
|
|
|
|
| |
In our scheme it's illegal for any message to refer to itself, (nor
would it be useful for anything anyway). Cut these self-references off
at the source, before they trip up any internal errors.
|
| |
|
|
|
|
|
| |
This function has only one caller, and that one caller was passing the
same value for both talloc_owner and the notmuch database. Dropping
the redundant argument simplifies the documentation of this function
considerably.
|
| |
|
|
| |
Oops. I should have actually compiled before pushing.
|
| |
|
|
|
|
|
|
|
|
| |
When this function was originally written, the 'message' object was
always destroyed locally, so I thought it would be good to use a NULL
talloc context to make it more obvious if there was any leak.
Since then, however, this function has been changed to optionally
return the added message, and in that case we *don't* free the message
locally, so let's let the database be the talloc context.
|
| |
|
|
|
| |
Nothing significant here, but we might as well not keep things
misspelled when we notice.
|
| |
|
|
|
|
| |
Not exported through the public interface, but the thread code is
going to want to be able to parse In-Reply-To headers so needs access
to this code.
|
| |
|
|
|
|
|
|
|
|
|
| |
We never did export any interface to get at these, and when I went to
use these, I found them inadequate, (because I wanted to distinguish
address found in from: from those found in To:). Meanwhile, it was
easy enough to extract addresses with a search like:
notmuch show tag:sent | grep ^To:
so the storage of contact terms was just wasting space. Stop that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow for things like the database path to be specified
without any cheesy NOTMUCH_BASE environment variable. It also will
allow "notmuch reply" to recognize the user's email address when
constructing a reply in order to do the right thing, (that is, to use
the user's address to which mail was sent as From:, and not to reply
to the user's own addresses).
With this change, the "notmuch setup" command is now strictly for
changing the configuration of notmuch. It no longer creates the
database, but instead instructs the user to call "notmuch new" to do
that.
|
|
|
A "make" invocation still works from the top-level, but not from
down inside the lib directory yet.
|
Chris Wilson
Carl Worth
Ingmar Vanhassel