From: Carl Worth <cworth@cworth.org>
To: Jed Brown <jed@59A2.org>, Jan Janak <jan@ryngle.com>
In-Reply-To: <87bpivtwr1.fsf@59A2.org>
References: <87fx87u3no.fsf@59A2.org> <874oon4pgv.fsf@yoom.home.cworth.org>
	<f35dbb950911211250u5f0e8c05p56da7be3d48bbba8@mail.gmail.com>
	<87bpivtwr1.fsf@59A2.org>
Date: Sat, 21 Nov 2009 23:46:44 +0100
Message-ID: <87ocmv338r.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Subject: Re: [notmuch] Asynchronous tagging
Precedence: list

On Sat, 21 Nov 2009 22:04:50 +0100, Jed Brown <jed@59A2.org> wrote:
> >  2) A client changes the flags on a message, for example, when you
> > read a message or mark it as deleted. Maildir stores flags in
> > filenames.
> 
> This seems like a problem.  I'm not familiar with xapian, is it
> necessarily an expensive operation to correct these inconsistencies?

There's not really anything Xapian-specific here. It should be a
relatively easy change to make notmuch do the right thing here. It just
happens that the original author/user of notmuch isn't using anything
that changes his filenames---so I hadn't noticed. :-)

> Matching by thread id ought to be cheap.

Naturally. And that's of course exactly what notmuch does. So in my
usage, the only time "notmuch new" sees a Message-ID that it has seen
before, is when it encounters a duplicate copy of a message. So the code
currently just ignores it.

Mikhail wrote a patch:

	1258491078-29658-1-git-send-email-dottedmag@dottedmag.net

that does the simple thing in this case of just noticing whether the old
filename has since been removed, and in this case updating the document
to the new filename.

The problem he ran into is that renames aren't updating mtimes and the
current "notmuch new" has an optimization to not even look at files
unless their mtime is newer than the mtime last seen for the directory
they are in.

So some investigation is needed to see how important that optimization
is, and if it's important to see whether there's another way to keep the
performance while being able to support renames. (Or alternately,
allowing the user to configure an option saying, "I need to support
renames even if that means that notmuch new is a bit slower.").

-Carl