From: Jani Nikula <jani@nikula.org>
To: Austin Clements <amdragon@mit.edu>,
Thomas Schwinge <thomas@schwinge.name>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH] Repeatability when copying a whole directory into a new one.
Date: Wed, 13 Apr 2016 22:50:03 +0300 [thread overview]
Message-ID: <87a8kxwaok.fsf@nikula.org> (raw)
In-Reply-To: <CAH-f9WuE3quh1jneP1Zj4+xB7r+AXwKbX0QfYvEwOQEKFG1F8Q@mail.gmail.com>
On Sat, 05 Nov 2011, Austin Clements <amdragon@mit.edu> wrote:
> 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.
Stumbled upon this one while checking old bug reports. Maybe the fix in
commit e26d99dc7b02f33299c281f97a13deaef802bc7a
Author: Jani Nikula <jani@nikula.org>
Date: Fri Sep 25 23:48:46 2015 +0300
cli: delete directory documents on directory removal
is inelegant, as it adds the API to remove directory document, but it's
there now. I was unaware of this bug report and your analysis at the
time.
BR,
Jani.
next prev parent reply other threads:[~2016-04-13 19:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 23:26 [PATCH] Repeatability when copying a whole directory into a new one Thomas Schwinge
2011-11-01 2:59 ` David Bremner
2011-11-03 16:49 ` Pieter Praet
2011-11-05 17:26 ` Austin Clements
2016-04-13 19:50 ` Jani Nikula [this message]
2011-12-18 13:08 ` Tomi Ollila
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a8kxwaok.fsf@nikula.org \
--to=jani@nikula.org \
--cc=amdragon@mit.edu \
--cc=notmuch@notmuchmail.org \
--cc=thomas@schwinge.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).