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 58A766DE17FB for ; Mon, 31 Aug 2015 16:43:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.533, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.55, 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 L9WnHlogszAN for ; Mon, 31 Aug 2015 16:43:50 -0700 (PDT) Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) by arlo.cworth.org (Postfix) with ESMTPS id F057C6DE1416 for ; Mon, 31 Aug 2015 16:43:49 -0700 (PDT) Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id t7VNhhA9010565; Mon, 31 Aug 2015 16:43:43 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7VNhhXk003003; Mon, 31 Aug 2015 16:43:43 -0700 (PDT) X-Authentication-Warning: market.scs.stanford.edu: dm set sender to return-qkx7targe2yr8nmf7e3uvkr4hi@ta.scs.stanford.edu using -f From: David Mazieres To: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= Subject: Re: muchsync files renames In-Reply-To: <87egijm7kw.fsf@freja.aidecoe.name> 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> Reply-To: David Mazieres expires 2015-11-29 PST Date: Mon, 31 Aug 2015 16:43:42 -0700 Message-ID: <878u8rvxap.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 31 Aug 2015 23:43:52 -0000 Amadeusz =C5=BBo=C5=82nowski writes: > Not necessarily. The recommended setup of notmuch for afew is that > "notmuch new" tags messages with "new" tag only. Then afew processes all > messages with "new" tag. So if it is a spam, then it gets "new" removed > and "spam" added. A spam message at any time doesn't have "unread" tag > assigned which should explain this behaviour. So the problem is to be > fixed on the afew side. 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 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. But, I suppose it might make sense for notmuch to special-case that flag. In other words, if notmuch new finds a file called: spam/new/nnn.MnnnPnnnQnRn.machine:2, 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. 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 what I'm wondering is how this is any different from what is already happening on the server. "notmuch new" should be doing what muchsync does in step 2, and afew (via "notmuch tag") should be doing what muchsync does in step 4. Yet somehow you are saying that on the server the file stays in spam/new/, while on the client muchsync's actions cause the file to move to spam/cur/? So that means there's still something I don't really understand--possibly the series of notmuch library calls happening server side (which I should then maybe emulate client side). None of this is super serious, beyond a one-time extra cost, but I like to understand things thoroughly, particularly when writing software that manipulates critical data like mail... It there any possibility that new.tags has a different setting on your client and server machines? Thanks, David