Re: notmuch dump: taking write-lock to protect from concurrent (cronned) notmuch new?

[Mark Walters <markwalters1009@gmail.com>]

On Fri, 06 Jun 2014, Maarten Aertsen <sagi-notmuch@rtsn.nl> wrote:
> Hi everyone,
>
> (summary of IRC-conversation just now)
> I did:
>   - run notmuch new (and afew -t) in cron, every two minutes
>   - run notmuch dump in cron, every 12 hours
>
> I expected:
>   - notmuch dump to complete, possibly causing notmuch new to fail in the meantime
>
> I observed:
>   - notmuch dump terminating with:
> "terminate called after throwing an instance of 'Xapian::DatabaseModifiedError'"
>
> mjw1009 suggested to change NOTMUCH_DATABASE_MODE_READ_ONLY on line
> 215 of notmuch-dump.c to NOTMUCH_DATABASE_MODE_READ_WRITE
>
> I'm wondering if this hits enough people to motivate the addition of a
> command line switch (or perhaps even a change in default behaviour?)

I think this is a clear bug but the fix is a little unclear. The above
fix works but it breaks one of the tests: "unicode message-ids" in
T150-tagging.sh.

I think the problem is that it does 
notmuch dump | sed... | notmuch restore

and if we open the dump read-write the restore will fail.

We can obviously fix the test, but I don't know if anyone is using a
pipe of this sort in their scripts. If this a likely problem then we
could offer a --no-lock option (which keeps the behaviour as now)

What do people think?

Best wishes

Mark