synchronize_flags leaving files in new (was muchsync files renames)

[dm-list-email-notmuch at scs.stanford.edu]

Amadeusz =C5=BBo=C5=82nowski <aidecoe at aidecoe.name> writes:

> What's more surprising is that there is a test case in notmuch test
> suite which test whether after modifing tag of a mail it is moved from
> new/ to cur/. Yes, it should be moved on any tag modification if I
> understand correctly. But it seems it does not for my maildirs...
>
> $ notmuch search --output=3Dfiles thread:00000000000108bf
> /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000=
FE04I0000000000141A38_0.freja,S=3D53857
> $ notmuch search thread:00000000000108bf
> thread:00000000000108bf  Yest. 11:58 [1/1] Somebody; Subject (reklama unr=
ead)
> $ notmuch tag +hey thread:00000000000108bf
> $ notmuch search thread:00000000000108bf
> thread:00000000000108bf  Yest. 11:58 [1/1] Somebody; Subject (hey reklama=
 unread)
> $ notmuch search --output=3Dfiles thread:00000000000108bf
> /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000=
FE04I0000000000141A38_0.freja,S=3D53857

First, just to be absolutely sure, doe the file exist?  It's conceivably
that notmuch search is returning stale data until the next time you run
notmuch new.  Not likely, but just trying to rule out all possibilities.

Second, I wonder if the ",S=3D53857" suffix (size) is throwing things off.
Perhaps libnotmuch only expects suffixes when they are of the form
",S=3D53857:2,<flags>."  Since muchsync does not add a size field (in
either the new or cur subdirectory), it could be leading to the
different behavior.  To test this, can you rename the file in the new
directory without the ",S=3D..." and see if the behavior changes?

Thanks,
David