Re: muchsync files renames
authorDavid Mazieres <dm-list-email-notmuch@scs.stanford.edu>
Sun, 23 Aug 2015 20:43:37 +0000 (13:43 +1700)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:49:24 +0000 (14:49 -0700)
e6/eac8e91078f661b40402b008003fbad56777f1 [new file with mode: 0644]

diff --git a/e6/eac8e91078f661b40402b008003fbad56777f1 b/e6/eac8e91078f661b40402b008003fbad56777f1
new file mode 100644 (file)
index 0000000..b3e3c4a
--- /dev/null
@@ -0,0 +1,81 @@
+Return-Path:\r
+ <return-ph3ayavez28xe94sjqm2b6vw8e@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 A0D5F6DE1405\r
+ for <notmuch@notmuchmail.org>; Sun, 23 Aug 2015 13:43:43 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.282\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.569,\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 nZul-DAygMvv for <notmuch@notmuchmail.org>;\r
+ Sun, 23 Aug 2015 13:43:42 -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 008C86DE13FE\r
+ for <notmuch@notmuchmail.org>; Sun, 23 Aug 2015 13:43:41 -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
+ t7NKhc77026522; Sun, 23 Aug 2015 13:43:38 -0700 (PDT)\r
+Received: (from dm@localhost)\r
+ by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7NKhc7a030300;\r
+ Sun, 23 Aug 2015 13:43:38 -0700 (PDT)\r
+X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
+ return-ph3ayavez28xe94sjqm2b6vw8e@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
+ notmuch@notmuchmail.org\r
+Subject: Re: muchsync files renames\r
+In-Reply-To: <87oahxojlv.fsf@ta.scs.stanford.edu>\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>\r
+Reply-To: David Mazieres expires 2015-11-21 PST\r
+ <mazieres-3tpqwgk82pbkbsf24cfhhxaqqw@temporary-address.scs.stanford.edu>\r
+Date: Sun, 23 Aug 2015 13:43:37 -0700\r
+Message-ID: <87lhd1ohvq.fsf@ta.scs.stanford.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\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: Sun, 23 Aug 2015 20:43:43 -0000\r
+\r
+So just to follow up a bit.  I looked into things a bit further, and\r
+here is what I found with maildir.synchronize_flags set to true.\r
+\r
+Initially, when you run "muchsync --init", it copies all the files to\r
+your maildir, and for each file invokes\r
+notmuch_message_tags_to_maildir_flag.  That changes the name of the\r
+file, with the result that the sql database and the actual mail\r
+directory end up out of sync.  That on it's own is not a big deal, but\r
+it means that the next time muchsync, muchsync will have to rescan all\r
+of the files, as their names are no longer correct.  That shouldn't\r
+cause any extra traffic between the two machines, but it will require\r
+time on the client.  That is likely the source of the delay you were\r
+seeing.\r
+\r
+However, if you C-c the client during this process, I still don't see\r
+any problems arising that cause more links to be transferred between\r
+machines.  So I'm kind of stumped about that part.\r
+\r
+Maybe muchsync should create the original file name based on tags, so as\r
+to avoid having to rescan in the common case.  I wish there were some\r
+way of getting the renamed file after\r
+notmuch_message_tags_to_maildir_flags.\r
+\r
+David\r