--- /dev/null
+Return-Path:\r
+ <return-qkx7targe2yr8nmf7e3uvkr4hi@temporary-address.scs.stanford.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 58A766DE17FB\r
+ for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 16:43:52 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.318\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.533,\r
+ RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001]\r
+ autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id L9WnHlogszAN for <notmuch@notmuchmail.org>;\r
+ Mon, 31 Aug 2015 16:43:50 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id F057C6DE1416\r
+ for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 16:43:49 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
+ [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
+ t7VNhhA9010565; Mon, 31 Aug 2015 16:43:43 -0700 (PDT)\r
+Received: (from dm@localhost)\r
+ by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7VNhhXk003003;\r
+ Mon, 31 Aug 2015 16:43:43 -0700 (PDT)\r
+X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
+ return-qkx7targe2yr8nmf7e3uvkr4hi@ta.scs.stanford.edu using -f\r
+From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
+To: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= <aidecoe@aidecoe.name>\r
+Subject: Re: muchsync files renames\r
+In-Reply-To: <87egijm7kw.fsf@freja.aidecoe.name>\r
+References: <878u93ujdo.fsf@freja.aidecoe.name>\r
+ <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name>\r
+ <87oahxojlv.fsf@ta.scs.stanford.edu> <87vbbwnbb4.fsf@freja.aidecoe.name>\r
+ <87io7wr50y.fsf@ta.scs.stanford.edu> <87k2sbmzww.fsf@freja.aidecoe.name>\r
+ <87oahnmkqf.fsf@ta.scs.stanford.edu> <87egijm7kw.fsf@freja.aidecoe.name>\r
+Reply-To: David Mazieres expires 2015-11-29 PST\r
+ <mazieres-sggp47c7j46624db3rharctcei@temporary-address.scs.stanford.edu>\r
+Date: Mon, 31 Aug 2015 16:43:42 -0700\r
+Message-ID: <878u8rvxap.fsf@ta.scs.stanford.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.18\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 31 Aug 2015 23:43:52 -0000\r
+\r
+Amadeusz =C5=BBo=C5=82nowski <aidecoe@aidecoe.name> writes:\r
+\r
+> Not necessarily. The recommended setup of notmuch for afew is that\r
+> "notmuch new" tags messages with "new" tag only. Then afew processes all\r
+> messages with "new" tag. So if it is a spam, then it gets "new" removed\r
+> and "spam" added. A spam message at any time doesn't have "unread" tag\r
+> assigned which should explain this behaviour. So the problem is to be\r
+> fixed on the afew side.\r
+\r
+Let's just make sure I understand: Your mail starts out like this:\r
+\r
+ Path: spam/new/nnn.MnnnPnnnQnRn.machine\r
+ Tags: new\r
+\r
+Then you run afew, and afew runs\r
+\r
+ notmuch tag -new +spam <message-ID>\r
+\r
+You are saying that that even though maildir.synchronize_tags is true,\r
+you end up with:\r
+\r
+ Path: spam/new/nnn.MnnnPnnnQnRn.machine\r
+ Tags: spam\r
+\r
+That's a little surprising, because the next time you run "notmuch new,"\r
+I would have expected it to add the unread flag based on the pathname.\r
+But, I suppose it might make sense for notmuch to special-case that\r
+flag. In other words, if notmuch new finds a file called:\r
+\r
+ spam/new/nnn.MnnnPnnnQnRn.machine:2,\r
+\r
+Then it will add the unread tag to the Xapian database. But maybe if it\r
+finds a file in the new folder it doesn't add the unread flag.\r
+\r
+But why does notmuch_message_tags_to_maildir_flag() then feel the need\r
+to rename the file when muchsync calls it. Muchsync should ideally\r
+behave exactly the same as the notmuch tag command. Specifically, when\r
+muchsync receives a new file from the server, it does the following:\r
+\r
+ 1. create file in same directory as the server (presumably spam/new)\r
+\r
+ 2. Call the following functions on this file:\r
+ notmuch_database_add_message()\r
+ notmuch_message_freeze()\r
+ notmuch_message_remove_all_tags()\r
+ notmuch_message_add_tag() for each tag in new.tags\r
+ if (synchronize_tags) notmuch_message_tags_to_maildir_flag()\r
+ notmuch_message_thaw()\r
+\r
+ 3. get the current tags of the message from the server (presumably just\r
+ spam)\r
+\r
+ 4. Call the following functions on the Message-ID:\r
+ notmuch_message_freeze()\r
+ notmuch_message_remove_all_tags()\r
+ notmuch_message_add_tag() for each tag sent *by the server*\r
+ if (synchronize_tags) notmuch_message_tags_to_maildir_flag()\r
+ notmuch_message_thaw()\r
+\r
+So what I'm wondering is how this is any different from what is already\r
+happening on the server. "notmuch new" should be doing what muchsync\r
+does in step 2, and afew (via "notmuch tag") should be doing what\r
+muchsync does in step 4.\r
+\r
+Yet somehow you are saying that on the server the file stays in\r
+spam/new/, while on the client muchsync's actions cause the file to move\r
+to spam/cur/? So that means there's still something I don't really\r
+understand--possibly the series of notmuch library calls happening\r
+server side (which I should then maybe emulate client side).\r
+\r
+None of this is super serious, beyond a one-time extra cost, but I like\r
+to understand things thoroughly, particularly when writing software that\r
+manipulates critical data like mail...\r
+\r
+It there any possibility that new.tags has a different setting on your\r
+client and server machines?\r
+\r
+Thanks,\r
+David\r
projects / notmuch-archives.git / commitdiff