RFC: Dovecot locking

Rob Browning writes: > This is an unfinished patch to handle Dovecot locking, which is useful > if we'd like to support running notmuch directly on a Dovecot Maildir: > > http://wiki.dovecot.org/MailboxFormat/Maildir#Locking > > For now, I'm interested in general comments, i.e. is this

emacs crashes

On Thu, 17 Feb 2011, Brian May wrote: > Hello, > > I have found certain emails, when I try to view them with the emacs > notmuch client, will cause emacs to crash (segmentation fault). Every > time, 100% reproducible. > > A theory of have is maybe the emails are too big and the system can't

[PATCH 10/10] new: Wrap adding a message in an atomic section.

This prevents atomicity violations when adding new messages. Each message add is wrapped in its own atomic section, so interrupting notmuch new doesn't loose progress. Unlike in the remove case, adding a message can modify more than one database document, necessitating full transactions. ---

[PATCH 09/10] lib: Add notmuch_database_{begin,end}_atomic.

These operations translate into non-flushed Xapian transactions, allowing arbitrary groups of database operations to be performed atomically. --- lib/database.cc | 44 lib/notmuch.h | 30 ++ 2 files changed, 74

[PATCH 08/10] new: Synchronize maildir flags eagerly.

Because flag synchronization is stateless, it can be performed at any time as long as it's guaranteed to be performed after any change to a message's filename list. Take advantage of this to synchronize tags immediately after a filename is added or removed while the message is still frozen. With

[PATCH 07/10] new: Use the new filename removal API.

This paves the way for eager tag synchronization and correct removal atomicity. --- notmuch-new.c | 35 +++ 1 files changed, 23 insertions(+), 12 deletions(-) diff --git a/notmuch-new.c b/notmuch-new.c index 65682d8..56fe7b0 100644 --- a/notmuch-new.c +++

[PATCH 06/10] lib: Add API's to find by filename and remove a filename from a message.

The two new API functions, notmuch_database_find_message_by_filename and notmuch_message_remove_filename give library users more control over the filename removal process. notmuch_database_remove_message has been reimplemented in terms of these new functions. notmuch_message_remove_filename acts

[PATCH 05/10] lib: Indicate if there are more filenames after removal.

Make _notmuch_message_remove_filename return NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID if the message has more filenames and fix callers to handle this. --- lib/message.cc | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/lib/message.cc b/lib/message.cc index

[PATCH 04/10] lib: Make _notmuch_message_sync capable of deleting a message.

--- lib/message.cc |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/lib/message.cc b/lib/message.cc index 0590f76..06747fe 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -29,6 +29,7 @@ struct _notmuch_message { notmuch_database_t *notmuch;

[PATCH 03/10] new: Defer updating directory mtimes until the end.

Previously, if notmuch new were interrupted between updating the directory mtime and handling removals from that directory, a subsequent notmuch new would not handle those removals until something else changed in that directory. This defers recording the updated mtime until after removals are

[PATCH 02/10] new: Don't loose messages on SIGINT.

Previously, message removals were always performed, even after a SIGINT. As a result, when a message was moved from one folder to another, a SIGINT between processing the directory the message was removed from and processing the directory it was added to would result in notmuch removing that

[PATCH 01/10] test: Test atomicity of notmuch new.

This tests notmuch new's ability to recover from arbitrary stopping failures. It interrupts notmuch new after every database commit and, on every resulting database snapshot, re-runs notmuch new to completion and checks that the final database state is invariant. --- test/atomicity | 90

[PATCH 00/10] Fix 'notmuch new' atomicity issues

This patch series modifies notmuch new to perform all operations atomically and to perform maildir flag synchronization eagerly. As a result, notmuch new can be interrupted without risking database consistency or losing track of messages, but still without losing progress in the middle of a big

[PATCH 05/10] lib: Indicate if there are more filenames after removal.

Make _notmuch_message_remove_filename return NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID if the message has more filenames and fix callers to handle this. --- lib/message.cc | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/lib/message.cc b/lib/message.cc index

[PATCH 06/10] lib: Add API's to find by filename and remove a filename from a message.

The two new API functions, notmuch_database_find_message_by_filename and notmuch_message_remove_filename give library users more control over the filename removal process. notmuch_database_remove_message has been reimplemented in terms of these new functions. notmuch_message_remove_filename acts

[PATCH 09/10] lib: Add notmuch_database_{begin,end}_atomic.

These operations translate into non-flushed Xapian transactions, allowing arbitrary groups of database operations to be performed atomically. --- lib/database.cc | 44 lib/notmuch.h | 30 ++ 2 files changed, 74

[PATCH 08/10] new: Synchronize maildir flags eagerly.

Because flag synchronization is stateless, it can be performed at any time as long as it's guaranteed to be performed after any change to a message's filename list. Take advantage of this to synchronize tags immediately after a filename is added or removed while the message is still frozen. With

Re: emacs crashes

On Thu, 17 Feb 2011, Brian May wrote: Hello, I have found certain emails, when I try to view them with the emacs notmuch client, will cause emacs to crash (segmentation fault). Every time, 100% reproducible. A theory of have is maybe the emails are too big and the system can't cope, eg: