From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 5997B6DE1329 for ; Tue, 1 Sep 2015 15:52:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=0.097, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOyg3aCieq3h for ; Tue, 1 Sep 2015 15:52:50 -0700 (PDT) Received: from jim.zolnowski.name (jim.zolnowski.name [188.116.54.122]) by arlo.cworth.org (Postfix) with ESMTPS id 0AA826DE1226 for ; Tue, 1 Sep 2015 15:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aidecoe.name; s=jim; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=vhgQQnGbpXfcbjn5ua5AJV+d7HbrVgbjYasxGwyQFP4=; b=knczbbPimt3+1oxoW0ql1igRU9pmckNniIqD4E3nEuZozafqEU9erjj5gekmEl4ms1NJFALOzjsPB1AU+6IQEGB3nXsZDmaFlG9mMP+xLL2YFe56qJYYZqDlD0fXnrcuUtg0OYbi0O4Pjk/laFjZVm8EanNW/wo/GNBJeS44EuLV/cytvQD85mA0PMQZFg4t83/gYwyjRIayeIQcHQb/VlD0uVT8DwamsH73grd0MX85ApQQQ3U15M+hRVuvEagBIu8dG7j8U0W7HLHjtwwVhzopP4wsCAZcSNIi/GhttxBrpdGZ2KQ3zcEHwRI/6M8gmTL4ELh4XKekYydMaOzoqA==; Received: from cpc3-cmbg17-2-0-cust294.5-4.cable.virginm.net ([86.22.65.39] helo=localhost) by jim.zolnowski.name with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZWuPy-0006K1-RC; Wed, 02 Sep 2015 00:52:43 +0200 From: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= To: David Mazieres expires 2015-11-29 PST Subject: Re: muchsync files renames In-Reply-To: <878u8rvxap.fsf@ta.scs.stanford.edu> References: <878u93ujdo.fsf@freja.aidecoe.name> <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name> <87oahxojlv.fsf@ta.scs.stanford.edu> <87vbbwnbb4.fsf@freja.aidecoe.name> <87io7wr50y.fsf@ta.scs.stanford.edu> <87k2sbmzww.fsf@freja.aidecoe.name> <87oahnmkqf.fsf@ta.scs.stanford.edu> <87egijm7kw.fsf@freja.aidecoe.name> <878u8rvxap.fsf@ta.scs.stanford.edu> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 01 Sep 2015 23:52:37 +0100 Message-ID: <87613tn45m.fsf@freja.aidecoe.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 22:52:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=3Dfiles thread:00000000000108bf /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000FE= 04I0000000000141A38_0.freja,S=3D53857 $ notmuch search thread:00000000000108bf thread:00000000000108bf Yest. 11:58 [1/1] Somebody; Subject (reklama unrea= d) $ notmuch tag +hey thread:00000000000108bf $ notmuch search thread:00000000000108bf thread:00000000000108bf Yest. 11:58 [1/1] Somebody; Subject (hey reklama u= nread) $ notmuch search --output=3Dfiles thread:00000000000108bf /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000FE= 04I0000000000141A38_0.freja,S=3D53857 > 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. =2D-=20 Amadeusz =C5=BBo=C5=82nowski --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJV5iw1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCMzcyRTFENjI5NUM1MzYwQTQwODQyRUZD QkNDODAyM0Y1OUUxNzA0AAoJEMvMgCP1nhcExfUP/2oRePjDcI+XXfvxzvN6Knbv JZgUF20evMpb5UhUW+4EJFpjE6GBiyY+RopbGduTHbf1eGGCNd6e4P2NlAVyZMcO YZeluU+upeH47w5qYacRKOTcq6+UIvsHsArLSgYCR1eV9RIMcZ/7sj83KDc8CNY8 uIunRoCn9Xpfm9QsnbfxzY3Vr4TqsvHaHc21MbjLk7ccNvTBYJqxtT+xZIZ5oxf4 bKzIxiPQnZYUTE60y9mk+PWHEMBIJZVLoMYPaK4v16LZf6jPP1i+WUvAHZLBYH04 lbEeQ42FMMBM71cWIz1kGwq0MQEEhMcsAq/Vlo8dIko873gkO5X3kgnaLleKzx66 VyQB9DwF2sewht844u0rYaJfCpLpy6Lz3JH0g/wcWD41LiakycFOudIGFem4tO7i pvfpCXS4nXFOqoRF+anT3aegM2KTcDzDDYRuJ3bXinxevfwUWb1583RkRvPSJw/p +lWJxuFb9wSQLtR+JBHAs6yfyoYywc5F4xeJck3Xryyp0HOU6sBTjcO5L5iQjUQB HWkCX+y/q4wtaL/u5+RxUsDprUD5GlKAnhpXVaNJ3wWZjqyn18Gp8n0QkeAROjfU qy51gKONHzwtiVDoa9cduArdLocHH5cMNOceKqh+HeB5+LG84JkRV/46p9tZ96PB LawSmgryk//VneCkeky4 =tHzz -----END PGP SIGNATURE----- --=-=-=--