29/92bb824485f0805bc811dacebfd9faa7890249

   1 Return-Path:\r
   2  <return-qkx7targe2yr8nmf7e3uvkr4hi@temporary-address.scs.stanford.edu>\r
   3 X-Original-To: notmuch@notmuchmail.org\r
   4 Delivered-To: notmuch@notmuchmail.org\r
   5 Received: from localhost (localhost [127.0.0.1])\r
   6  by arlo.cworth.org (Postfix) with ESMTP id 58A766DE17FB\r
   7  for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 16:43:52 -0700 (PDT)\r
   8 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.318\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.533,\r
  13   RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001]\r
  14  autolearn=disabled\r
  15 Received: from arlo.cworth.org ([127.0.0.1])\r
  16  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17  with ESMTP id L9WnHlogszAN for <notmuch@notmuchmail.org>;\r
  18  Mon, 31 Aug 2015 16:43:50 -0700 (PDT)\r
  19 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  20  by arlo.cworth.org (Postfix) with ESMTPS id F057C6DE1416\r
  21  for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 16:43:49 -0700 (PDT)\r
  22 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  23  [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
  24  t7VNhhA9010565; Mon, 31 Aug 2015 16:43:43 -0700 (PDT)\r
  25 Received: (from dm@localhost)\r
  26  by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7VNhhXk003003;\r
  27  Mon, 31 Aug 2015 16:43:43 -0700 (PDT)\r
  28 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  29  return-qkx7targe2yr8nmf7e3uvkr4hi@ta.scs.stanford.edu using -f\r
  30 From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
  31 To: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= <aidecoe@aidecoe.name>\r
  32 Subject: Re: muchsync files renames\r
  33 In-Reply-To: <87egijm7kw.fsf@freja.aidecoe.name>\r
  34 References: <878u93ujdo.fsf@freja.aidecoe.name>\r
  35  <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name>\r
  36  <87oahxojlv.fsf@ta.scs.stanford.edu> <87vbbwnbb4.fsf@freja.aidecoe.name>\r
  37  <87io7wr50y.fsf@ta.scs.stanford.edu> <87k2sbmzww.fsf@freja.aidecoe.name>\r
  38  <87oahnmkqf.fsf@ta.scs.stanford.edu> <87egijm7kw.fsf@freja.aidecoe.name>\r
  39 Reply-To: David Mazieres expires 2015-11-29 PST\r
  40  <mazieres-sggp47c7j46624db3rharctcei@temporary-address.scs.stanford.edu>\r
  41 Date: Mon, 31 Aug 2015 16:43:42 -0700\r
  42 Message-ID: <878u8rvxap.fsf@ta.scs.stanford.edu>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: text/plain; charset=utf-8\r
  45 Content-Transfer-Encoding: quoted-printable\r
  46 Cc: notmuch@notmuchmail.org\r
  47 X-BeenThere: notmuch@notmuchmail.org\r
  48 X-Mailman-Version: 2.1.18\r
  49 Precedence: list\r
  50 List-Id: "Use and development of the notmuch mail system."\r
  51  <notmuch.notmuchmail.org>\r
  52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  53  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  54 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  55 List-Post: <mailto:notmuch@notmuchmail.org>\r
  56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  58  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  59 X-List-Received-Date: Mon, 31 Aug 2015 23:43:52 -0000\r
  60 \r
  61 Amadeusz =C5=BBo=C5=82nowski <aidecoe@aidecoe.name> writes:\r
  62 \r
  63 > Not necessarily. The recommended setup of notmuch for afew is that\r
  64 > "notmuch new" tags messages with "new" tag only. Then afew processes all\r
  65 > messages with "new" tag. So if it is a spam, then it gets "new" removed\r
  66 > and "spam" added. A spam message at any time doesn't have "unread" tag\r
  67 > assigned which should explain this behaviour.  So the problem is to be\r
  68 > fixed on the afew side.\r
  69 \r
  70 Let's just make sure I understand:  Your mail starts out like this:\r
  71 \r
  72     Path:  spam/new/nnn.MnnnPnnnQnRn.machine\r
  73     Tags:  new\r
  74 \r
  75 Then you run afew, and afew runs\r
  76 \r
  77     notmuch tag -new +spam <message-ID>\r
  78 \r
  79 You are saying that that even though maildir.synchronize_tags is true,\r
  80 you end up with:\r
  81 \r
  82     Path:  spam/new/nnn.MnnnPnnnQnRn.machine\r
  83     Tags:  spam\r
  84 \r
  85 That's a little surprising, because the next time you run "notmuch new,"\r
  86 I would have expected it to add the unread flag based on the pathname.\r
  87 But, I suppose it might make sense for notmuch to special-case that\r
  88 flag.  In other words, if notmuch new finds a file called:\r
  89 \r
  90     spam/new/nnn.MnnnPnnnQnRn.machine:2,\r
  91 \r
  92 Then it will add the unread tag to the Xapian database.  But maybe if it\r
  93 finds a file in the new folder it doesn't add the unread flag.\r
  94 \r
  95 But why does notmuch_message_tags_to_maildir_flag() then feel the need\r
  96 to rename the file when muchsync calls it.  Muchsync should ideally\r
  97 behave exactly the same as the notmuch tag command.  Specifically, when\r
  98 muchsync receives a new file from the server, it does the following:\r
  99 \r
 100  1. create file in same directory as the server (presumably spam/new)\r
 101 \r
 102  2. Call the following functions on this file:\r
 103       notmuch_database_add_message()\r
 104       notmuch_message_freeze()\r
 105       notmuch_message_remove_all_tags()\r
 106       notmuch_message_add_tag() for each tag in new.tags\r
 107       if (synchronize_tags) notmuch_message_tags_to_maildir_flag()\r
 108       notmuch_message_thaw()\r
 109 \r
 110  3. get the current tags of the message from the server (presumably just\r
 111     spam)\r
 112 \r
 113  4. Call the following functions on the Message-ID:\r
 114       notmuch_message_freeze()\r
 115       notmuch_message_remove_all_tags()\r
 116       notmuch_message_add_tag() for each tag sent *by the server*\r
 117       if (synchronize_tags) notmuch_message_tags_to_maildir_flag()\r
 118       notmuch_message_thaw()\r
 119 \r
 120 So what I'm wondering is how this is any different from what is already\r
 121 happening on the server.  "notmuch new" should be doing what muchsync\r
 122 does in step 2, and afew (via "notmuch tag") should be doing what\r
 123 muchsync does in step 4.\r
 124 \r
 125 Yet somehow you are saying that on the server the file stays in\r
 126 spam/new/, while on the client muchsync's actions cause the file to move\r
 127 to spam/cur/?  So that means there's still something I don't really\r
 128 understand--possibly the series of notmuch library calls happening\r
 129 server side (which I should then maybe emulate client side).\r
 130 \r
 131 None of this is super serious, beyond a one-time extra cost, but I like\r
 132 to understand things thoroughly, particularly when writing software that\r
 133 manipulates critical data like mail...\r
 134 \r
 135 It there any possibility that new.tags has a different setting on your\r
 136 client and server machines?\r
 137 \r
 138 Thanks,\r
 139 David\r