MIME-Version: 1.0
Sender: amdragon@gmail.com
In-Reply-To: <1317338806-7414-1-git-send-email-thomas@schwinge.name>
References: <1317338806-7414-1-git-send-email-thomas@schwinge.name>
Date: Sat, 5 Nov 2011 13:26:03 -0400
Message-ID:
 <CAH-f9WuE3quh1jneP1Zj4+xB7r+AXwKbX0QfYvEwOQEKFG1F8Q@mail.gmail.com>
Subject: Re: [PATCH] Repeatability when copying a whole directory into a new
	one.
From: Austin Clements <amdragon@mit.edu>
To: Thomas Schwinge <thomas@schwinge.name>
Content-Type: text/plain; charset=ISO-8859-1
Cc: notmuch@notmuchmail.org
Precedence: list

On Thu, Sep 29, 2011 at 7:26 PM, Thomas Schwinge <thomas@schwinge.name> wrote:
> This new test currently fails -- but it shouldn't.
> ---
>
> Hi!
>
> I found this while manually copying directories and running notmuch new.
>
> Am I just too sleepy at this time, or is it another DB vs. directory
> mtime issue?

Nice catch.  I haven't verified this, but I believe the problem is
that notmuch never deletes directory documents.  In fact, there isn't
even an API to do so.  Even though it detects the deleted directory
and deletes all messages under it, the directory document sticks
around.  When the directory comes back, notmuch finds the old
directory document with the old directory mtime and thinks it doesn't
have to rescan the directory because the cp -a reproduced the same
mtime the directory used to have.

So, I guess part of the answer is "don't cp -a" because that mucks
with mtimes and mtimes are all notmuch has to go by.  But that's no
excuse for not removing the directory documents when the directory is
removed.

Fixing this is slightly tricky.  I feel like there *shouldn't* be an
API to simply remove a directory document because that would let you
violate database consistency.  Instead, I think the API should
recursively remove everything under the removed directory, exactly
like what notmuch-new.c:_remove_directory does right now (plus
removing the directory documents).  But _remove_directory depends on
remove_filename, which currently has notmuch-new-specific logic in it.
 I feel like there must be a nice solution to this, and I'm just not
thinking of it.