From: David Mazieres Date: Mon, 31 Aug 2015 23:43:42 +0000 (+1700) Subject: Re: muchsync files renames X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=7267927d8a24357c810e54c367c33392dd4c7b84;p=notmuch-archives.git Re: muchsync files renames --- diff --git a/29/92bb824485f0805bc811dacebfd9faa7890249 b/29/92bb824485f0805bc811dacebfd9faa7890249 new file mode 100644 index 000000000..33c4847a2 --- /dev/null +++ b/29/92bb824485f0805bc811dacebfd9faa7890249 @@ -0,0 +1,139 @@ +Return-Path: + +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +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