Return-Path: <sojkam1@fel.cvut.cz>
X-Original-To: notmuch@notmuchmail.org
Delivered-To: notmuch@notmuchmail.org
Received: from localhost (localhost [127.0.0.1])
	by olra.theworths.org (Postfix) with ESMTP id EA87A431FBC
	for <notmuch@notmuchmail.org>; Tue,  9 Feb 2010 09:20:07 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
X-Spam-Flag: NO
X-Spam-Score: -1.067
X-Spam-Level: 
X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5
	tests=[AWL=-1.068, BAYES_50=0.001] autolearn=ham
Received: from olra.theworths.org ([127.0.0.1])
	by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id JG6Rawk7Dh2d for <notmuch@notmuchmail.org>;
	Tue,  9 Feb 2010 09:20:07 -0800 (PST)
Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])
	by olra.theworths.org (Postfix) with ESMTP id E61AE431FAE
	for <notmuch@notmuchmail.org>; Tue,  9 Feb 2010 09:20:06 -0800 (PST)
Received: from localhost (unknown [192.168.200.4])
	by max.feld.cvut.cz (Postfix) with ESMTP id 293F019F3300;
	Tue,  9 Feb 2010 18:20:06 +0100 (CET)
X-Virus-Scanned: IMAP AMAVIS
Received: from max.feld.cvut.cz ([192.168.200.1])
	by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,
	port 10044)
	with ESMTP id OiiS8K9mMr9U; Tue,  9 Feb 2010 18:20:02 +0100 (CET)
Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])
	by max.feld.cvut.cz (Postfix) with ESMTP id 1D34919F3333;
	Tue,  9 Feb 2010 18:20:02 +0100 (CET)
Received: from steelpick.localdomain (k335-30.felk.cvut.cz [147.32.86.30])
	(Authenticated sender: sojkam1)
	by imap.feld.cvut.cz (Postfix) with ESMTPSA id 15B7DFA003;
	Tue,  9 Feb 2010 18:20:02 +0100 (CET)
Received: from wsh by steelpick.localdomain with local (Exim 4.71)
	(envelope-from <sojkam1@fel.cvut.cz>)
	id 1Netkn-0006gW-UA; Tue, 09 Feb 2010 18:20:02 +0100
From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Brett Viren <brett.viren@gmail.com>, notmuch@notmuchmail.org
In-Reply-To: <46263c601002090738k6a8f0e92v807b535918cbc7a5@mail.gmail.com>
References: <46263c601002090738k6a8f0e92v807b535918cbc7a5@mail.gmail.com>
Date: Tue, 09 Feb 2010 18:20:01 +0100
Message-ID: <87ljf2jpha.fsf@steelpick.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [notmuch] Problems with Maildir and files moving from new/ to
 cur/
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: "Use and development of the notmuch mail system."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2010 17:20:08 -0000

On Tue, 9 Feb 2010 10:38:04 -0500, Brett Viren <brett.viren@gmail.com> wrote:
> Hi,
> 
> I use procmail to prefilter mail into various sub groups of a Maildir.
>  This Maildir is served by dovecot IMAP and is also visible to
> notmuch.  I run "notmuch new" followed by "notmuch tag -inbox -unread
> tag:inbox" (I use GNUS to do my reading and don't want these tags in
> the way the few times I run notmuch for reading) every 10 minutes from
> cron.  I often will check my email before the cron job gets a chance
> to run and vice versa.
> 
> The problem I have is that this race condition means that sometimes
> notmuch will index a message as being under the Maildir/.<topic>/new/
> subdirectory, I then read it and it is moved to Maildir/.<topic>/cur/
> (I think that is what is happening).  Then when I do a search, notmuch
> returns a file that is no longer around.
> 
> This may not be an issue with notmuch, per se, but does anyone have
> any suggestions to make this work more smoothly?

Hi,

I'm afraid that with current version there is no solution for this.
There were some proposals to tell notmuch which files you want to index
and use this functionality to run indexing right on delivery on when a
rename is detected (e.g. by inotify). See
id:1264719647-sup-9540@ben-laptop for details. AFAIK nobody have sent
patches for this yet.

Cheers,
Michal