DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=sender:from:to:subject:in-reply-to:references:date:message-id
	:mime-version:content-type;
	b=cVfpFteZfHjkpDE1QDNJc6F7+dazVvT9pi2snrYIL2lwS+RTQpxmuIrl03RJBQDOyJ
	ZAtvWyuGOcz8d15cnsqIzHiQgTFdznlz2dugtVourfL/Da9y5hfIrphuiIs42/eyCeKv
	LiYB3ywXMvOhoXkWUKqget7uCjw27G373dxG8=
Sender: Jed Brown <five9a2@gmail.com>
From: Jed Brown <jed@59A2.org>
To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
In-Reply-To: <87tywn386a.fsf@yoom.home.cworth.org>
References: <87fx87u3no.fsf@59A2.org> <87einru0f9.fsf@59A2.org>
	<87tywn386a.fsf@yoom.home.cworth.org>
Date: Sat, 21 Nov 2009 22:17:34 +0100
Message-ID: <87aayftw5t.fsf@59A2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [notmuch] Asynchronous tagging
Precedence: list

On Sat, 21 Nov 2009 22:00:13 +0100, Carl Worth <cworth@cworth.org> wrote:
> Ah, OK. So you made a change on the Gmail side and that caused a file to
> be renamed locally.

yes

> Or did you mean you removed the tag from within emacs? In that case, the
> search term used to find the message is the message id itself. (Try
> running "M-x visible-mode" from a notmuch-search view in emacs to see
> what those look like.)

Exactly, that's what I meant by manually.  Those messages don't match a
nice generic pattern.

> Meanwhile, just archiving the message won't make things perfect for
> you. The document in the database point to the broken file is still
> there. And it should still have all of its terms, so will likely show up
> if you do more searches. (The "(null)" stuff you're seeing isn't because
> the message is NULL---for example, notmuch was able to find the date,
> etc. It's just that notmuch couldn't find the subject and authors when
> it went to look for the file.)

Yeah.

> So if GMail+offlineimap continues to shuffle your files around, you're
> going to keep seeing more and more confusion like this buildup.
> 
> So we really just need to teach notmuch how to handle an unstable file
> store in order to be able to use it in this kind of setup.

This seems unavoidable with maildir in the presence of any
synchronization, or use of a different client.

An ugly, but possible solution would be to mirror the entire maildir via
hard links with whatever naming scheme you like.  You then have a stable
link to the file and can resolve changing names in the real maildir.
This eats up a lot of inodes.

Jed