David Mazieres <dm-list-email-notmuch@scs.stanford.edu> writes: > So my question remains, what's the easiest safe way to re-enable > synchronize_flags after disabling it? (Safe meaning it won't change any > tags.) It could be that there's a very simple answer, in which case > sticking it in the man page might be nice. I can't think of a simple, safe, and fast answer. As a hack, if you run notmuch new right before you enable synchronize_flags, then next the next notmuch new will not notice the fact that flags are out of sync [1]. I don't think this really qualifies as safe, as the fact that the maildir is out of sync with the database will eventually bite you. Maybe in some special circumstances this helps. Otherwise, two things to that might speed up the process. 1) dump and restore both take queries, so you can only worry about the maildir relevant flags. 2) when the lastmod changes go in, it seems like you could run the first notmuch new after enabling tag synchonizing, and dump only the tag changes since a checkpoint lastmod value. This would allow rolling back the unwanted tag changes. [1]: see this potential test, if for some reason we wanted to guarantee this behaviours. test_begin_subtest "Turning on maildir.synchronize_flags w/o backup" OLDCONFIG=$(notmuch config get maildir.synchronize_flags) notmuch config set maildir.synchronize_flags true add_message [subject]='"Message to test ignoring flags"' \ [date]='"Sat, 01 Jan 2000 12:00:00 -0000"' \ [filename]='ignoring-flags' [dir]=cur ${NOTMUCH_NEW} notmuch dump > EXPECTED notmuch config set maildir.synchronize_flags false # make flags out of sync with db mv ${MAIL_DIR}/cur/ignoring-flags ${MAIL_DIR}/cur/ignoring-flags,S ${NOTMUCH_NEW} notmuch config set maildir.synchronize_flags true ${NOTMUCH_NEW} notmuch dump > OUTPUT notmuch config set maildir.synchronize_flags "${OLDCONFIG}" test_expect_equal_file EXPECTED OUTPUT