David Mazieres writes: > What happens if you get a message that's been stuck in a queue for a few > days and has an old Date: header? It would be missed. I have set the timespan to look backwards for new mail to one month to be a bit safer against the stuck-in-queue cases, but mails with older Date: headers would definitely get missed. The current output of notmuch count "*" is the same on both the client and the server, so it seems I didn't run into this problem yet (maybe I was just lucky). > Or if you get new messages that have > the same Message-ID as old ones? Is that even possible? I thought that notmuch guarantees the uniqueness of indexed message ids. The only reference I could find without trying to read the code was this thread id:87mwyz3s9d.fsf@star.eba from 2012, which supports the assumption. >> 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". I have one laptop and one desktop and switch between them almost daily, and run a hibernate script that does notmuch dump + git push, and a resume script that does git pull + notmuch restore. For hibernate / resume the speed of those operations is acceptable, but I wouldn't want to incur that wait for every time checking for new mail. Here is how long they take (on a machine with an SSD, which certainly helps): $ time notmuch dump --format=batch-tag | sort > /tmp/notmuch.dump real 0m3.643s user 0m3.593s sys 0m0.140s $ time notmuch restore < /tmp/notmuch.dump real 0m3.719s user 0m3.357s sys 0m0.357s $ notmuch count 117118 Til