11:19 a.m.
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
10:19 a.m.
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>
http://karelzak.blogspot.com
4406
days inactive
4409
days old
mutt-kz@lists.fedoraproject.org
1 comments
2 participants
participants (2)
-
Daren Lord -
Karel Zak