Tilmann Singer <tils@tils.net> writes: > The steps performed on a sync run are roughly like this: > > - local: notmuch new > - local: notmuch search --output=messages <some time ago>..<now> > - remote: notmuch new > - remote: notmuch search --output=messages <some time ago>..<now> > - compare search results > - run rsync for mails that only exist locally > (using notmuch search --output=files to get the filenames) > - run rsync for mails that only exist remotely > (using notmuch search --output=files to get the filenames) What happens if you get a message that's been stuck in a queue for a few days and has an old Date: header? Or if you get new messages that have the same Message-ID as old ones? > Synchronization of the notmuch tags database is only necessary when I > switch between different client computers, which happens less > frequently. Do you use a laptop everywhere? I've found that for switching between my desktop machine at home, my laptop on the train, and my desktop at work (which amounts to five switches a day), the notmuch dump time is painfully slow--like well over 10 seconds for 100,000 messages. Hook that into notmuch-poll and you have a recipe for hanging emacs every time you type "G". Of course, I'm also experiencing the problem of "notmuch new" itself being painfully slow, but at least that's now my bottleneck in switching machines. I suspect the source of the notmuch new problem is that I have some huge, huge mailboxes. Some of my maildir/cur directories are multiple megabytes on a BSD FFS file system (no hashing, so linear filename lookups in something that doesn't fit in the dcache). On linux ext4 things are much faster. I intend to reorganize my maildir so that there is a top-level directory with the year and hence no single directory ever contains mail from more than one year. David