Re: muchsync files renames
David Bremner writes: > Amadeusz Żołnowski 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... >> > > If I understand the code correctly, this movement will only happen when > one of the maildir-flag-equivalent tags is changed. I haven't dug ack > through the archives, but I think mutt uses presence in new/ as some > kind of extra unseen state, so people requested not to move files until > needed. Can you explain how/where this is implemented? I would like muchsync to do exactly what notmuch does, and ideally without replicating its logic, if I can just have libnotmuch handle this. Currently, my code looks something like this: notmuch_message_freeze() notmuch_message_remove_all_tags() notmuch_message_add_tag(); notmuch_message_add_tag(); ... if (synchronize_tags) notmuch_message_tags_to_maildir_flag() notmuch_message_thaw() And what we're finding is the above code causes the message to move from new/ to cur/, while the "notmuch tag" command does not, even while changing between the same before and after tag sets. Any ideas? Thanks, David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: muchsync files renames
Amadeusz Żołnowski 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... > If I understand the code correctly, this movement will only happen when one of the maildir-flag-equivalent tags is changed. I haven't dug ack through the archives, but I think mutt uses presence in new/ as some kind of extra unseen state, so people requested not to move files until needed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
synchronize_flags leaving files in new (was muchsync files renames)
Amadeusz =C5=BBo=C5=82nowski 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:000108bf > /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V= FE04I00141A38_0.freja,S=3D53857 > $ notmuch search thread:000108bf > thread:000108bf Yest. 11:58 [1/1] Somebody; Subject (reklama unr= ead) > $ notmuch tag +hey thread:000108bf > $ notmuch search thread:000108bf > thread:000108bf Yest. 11:58 [1/1] Somebody; Subject (hey reklama= unread) > $ notmuch search --output=3Dfiles thread:000108bf > /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V= FE04I00141A38_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,." 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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: muchsync files renames
Hi David, David Mazieres writes: > Let's just make sure I understand: Your mail starts out like this: > > Path: spam/new/nnn.MnnnPnnnQnRn.machine > Tags: new > > Then you run afew, and afew runs > > notmuch tag -new +spam > > You are saying that that even though maildir.synchronize_tags is true, > you end up with: > > Path: spam/new/nnn.MnnnPnnnQnRn.machine > Tags: spam Yes. > That's a little surprising, because the next time you run "notmuch new," > I would have expected it to add the unread flag based on the pathname. 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=files thread:000108bf /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412VFE04I00141A38_0.freja,S=53857 $ notmuch search thread:000108bf thread:000108bf Yest. 11:58 [1/1] Somebody; Subject (reklama unread) $ notmuch tag +hey thread:000108bf $ notmuch search thread:000108bf thread:000108bf Yest. 11:58 [1/1] Somebody; Subject (hey reklama unread) $ notmuch search --output=files thread:000108bf /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412VFE04I00141A38_0.freja,S=53857 > Then it will add the unread tag to the Xapian database. But maybe if it > finds a file in the new folder it doesn't add the unread flag. Might be. > But why does notmuch_message_tags_to_maildir_flag() then feel the need > to rename the file when muchsync calls it. Muchsync should ideally > behave exactly the same as the notmuch tag command. Specifically, when > muchsync receives a new file from the server, it does the following: > > 1. create file in same directory as the server (presumably spam/new) > > 2. Call the following functions on this file: > notmuch_database_add_message() > notmuch_message_freeze() > notmuch_message_remove_all_tags() > notmuch_message_add_tag() for each tag in new.tags > if (synchronize_tags) notmuch_message_tags_to_maildir_flag() > notmuch_message_thaw() > > 3. get the current tags of the message from the server (presumably just > spam) > > 4. Call the following functions on the Message-ID: > notmuch_message_freeze() > notmuch_message_remove_all_tags() > notmuch_message_add_tag() for each tag sent *by the server* > if (synchronize_tags) notmuch_message_tags_to_maildir_flag() > notmuch_message_thaw() So for some reason in my maildirs mails are not moved from new/ to cur/ on tag manipulation, but they are on client side by muchsync. I will have to investigate why this happens to me. -- Amadeusz Żołnowski signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
