Best use for pulling emails

[Daren Lord]

I am loving the mutt and notmuch integration but had a question whether or
not offlineimap is the best way to pull down my email and index it.

I do not have direct access to the mail server so offlineimap has been the
best way to go, thus far. I am also using the postsync-hooks in offlineimap
to call the notmuch-poll to start the new mail indexing.

My question is how to avoid Mutt and notmuch-poll locking the notmuch
database at the same time causing Mutt to crash. Am I doing something wrong
or is there a better method?

I have worked around this by waiting to make label changes until after
offlineimap finishes.

Any tips are welcome.

Thanks again for putting together the integration of mutt and offlineimap.

Dlord

[Karel Zak]

On Mon, Apr 02, 2012 at 10:19:15AM -0600, Daren Lord wrote:
>  I am loving the mutt and notmuch integration but had a question
> whether or
>  not offlineimap is the best way to pull down my email and index it. 
 I use fetchmail, but it's probably completely irrelevant. The more
 important is the next step -- procmail.

 I use notmuch-deliver (available in notmuch contrib) to deliver
 emails to maildirs and to add tags to notmuch DB.

  imap -> fetchmail -> procmail -> notmuch-deliver ---> maildir
                                                   `--> notmuch DB

 It means that the notmuch DB is locked only for very short time
 (only when notmuch-deliver is delivering the email).

 For example .procmailrc:

  :0:notmuch.lock
  * ^List-Id:.*mutt-kz
  | notmuch-deliver -t <tag> -t <tag> ...  <maildir>

>  I do not have direct access to the mail server so offlineimap has
> been the
>  best way to go, thus far. I am also using the postsync-hooks in offlineimap
>  to call the notmuch-poll to start the new mail indexing. 
 I don't like the global post-delivery indexing usually suggested by people
 around notmuch upstream, for example:

 http://notmuchmail.org/pipermail/notmuch/2010/001691.html


>  My question is how to avoid Mutt and notmuch-poll locking the
> notmuch
>  database at the same time causing Mutt to crash. Am I doing something wrong
>  or is there a better method? 
 Not sure if we can void this  ... (although Xapian DB used by notmuch
 probably supports single-writer and multiple-reader access).

 The solution is to minimize time when the database is locked by another
 process. The mutt keeps the database open for necessary time only.

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com