David Mazieres <dm-list-email-notm...@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

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 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 config set maildir.synchronize_flags true
notmuch dump > OUTPUT
notmuch config set maildir.synchronize_flags "${OLDCONFIG}"
test_expect_equal_file EXPECTED OUTPUT
notmuch mailing list

Reply via email to