On Thu, Sep 29, 2011 at 7:26 PM, Thomas Schwinge <thomas at 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.