e6/eac8e91078f661b40402b008003fbad56777f1

   1 Return-Path:\r
   2  <return-ph3ayavez28xe94sjqm2b6vw8e@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 A0D5F6DE1405\r
   7  for <notmuch@notmuchmail.org>; Sun, 23 Aug 2015 13:43:43 -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.282\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.569,\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 nZul-DAygMvv for <notmuch@notmuchmail.org>;\r
  18  Sun, 23 Aug 2015 13:43:42 -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 008C86DE13FE\r
  21  for <notmuch@notmuchmail.org>; Sun, 23 Aug 2015 13:43:41 -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  t7NKhc77026522; Sun, 23 Aug 2015 13:43:38 -0700 (PDT)\r
  25 Received: (from dm@localhost)\r
  26  by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7NKhc7a030300;\r
  27  Sun, 23 Aug 2015 13:43:38 -0700 (PDT)\r
  28 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  29  return-ph3ayavez28xe94sjqm2b6vw8e@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  notmuch@notmuchmail.org\r
  33 Subject: Re: muchsync files renames\r
  34 In-Reply-To: <87oahxojlv.fsf@ta.scs.stanford.edu>\r
  35 References: <878u93ujdo.fsf@freja.aidecoe.name>\r
  36  <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name>\r
  37  <87oahxojlv.fsf@ta.scs.stanford.edu>\r
  38 Reply-To: David Mazieres expires 2015-11-21 PST\r
  39  <mazieres-3tpqwgk82pbkbsf24cfhhxaqqw@temporary-address.scs.stanford.edu>\r
  40 Date: Sun, 23 Aug 2015 13:43:37 -0700\r
  41 Message-ID: <87lhd1ohvq.fsf@ta.scs.stanford.edu>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: text/plain\r
  44 X-BeenThere: notmuch@notmuchmail.org\r
  45 X-Mailman-Version: 2.1.18\r
  46 Precedence: list\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48  <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  50  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Sun, 23 Aug 2015 20:43:43 -0000\r
  57 \r
  58 So just to follow up a bit.  I looked into things a bit further, and\r
  59 here is what I found with maildir.synchronize_flags set to true.\r
  60 \r
  61 Initially, when you run "muchsync --init", it copies all the files to\r
  62 your maildir, and for each file invokes\r
  63 notmuch_message_tags_to_maildir_flag.  That changes the name of the\r
  64 file, with the result that the sql database and the actual mail\r
  65 directory end up out of sync.  That on it's own is not a big deal, but\r
  66 it means that the next time muchsync, muchsync will have to rescan all\r
  67 of the files, as their names are no longer correct.  That shouldn't\r
  68 cause any extra traffic between the two machines, but it will require\r
  69 time on the client.  That is likely the source of the delay you were\r
  70 seeing.\r
  71 \r
  72 However, if you C-c the client during this process, I still don't see\r
  73 any problems arising that cause more links to be transferred between\r
  74 machines.  So I'm kind of stumped about that part.\r
  75 \r
  76 Maybe muchsync should create the original file name based on tags, so as\r
  77 to avoid having to rescan in the common case.  I wish there were some\r
  78 way of getting the renamed file after\r
  79 notmuch_message_tags_to_maildir_flags.\r
  80 \r
  81 David\r