synchronize_flags leaving files in new (was muchsync files renames)
authordm-list-email-notmuch <dm-list-email-notmuch@scs.stanford.edu>
Tue, 1 Sep 2015 23:20:47 +0000 (16:20 +1700)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:49:29 +0000 (14:49 -0700)
4a/1ab625c983e6e6d991a63dcedab29a65b6f69f [new file with mode: 0644]

diff --git a/4a/1ab625c983e6e6d991a63dcedab29a65b6f69f b/4a/1ab625c983e6e6d991a63dcedab29a65b6f69f
new file mode 100644 (file)
index 0000000..a0ef97b
--- /dev/null
@@ -0,0 +1,92 @@
+Return-Path:\r
+ <return-an37y6qdnry79n9gtm96hbshya@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 B63E66DE175C\r
+ for <notmuch@notmuchmail.org>; Tue,  1 Sep 2015 16:31:08 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.729\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5\r
+ tests=[AWL=-0.085, MISSING_HEADERS=1.207, RCVD_IN_DNSWL_MED=-2.3,\r
+ RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001] 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 q0AZFp7i3r7q for <notmuch@notmuchmail.org>;\r
+ Tue,  1 Sep 2015 16:31:07 -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 D156A6DE1329\r
+ for <notmuch@notmuchmail.org>; Tue,  1 Sep 2015 16:31:06 -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
+ t81NV6nw028693 for <notmuch@notmuchmail.org>; Tue, 1 Sep 2015 16:31:06 -0700\r
+ (PDT)\r
+Received: (from dm@localhost)\r
+ by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t81NV6DU027092;\r
+ Tue, 1 Sep 2015 16:31:06 -0700 (PDT)\r
+X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
+ return-an37y6qdnry79n9gtm96hbshya@ta.scs.stanford.edu using -f\r
+From: dm-list-email-notmuch@scs.stanford.edu\r
+Cc: notmuch@notmuchmail.org\r
+Subject: synchronize_flags leaving files in new (was muchsync files renames)\r
+In-Reply-To: <87613tn45m.fsf@freja.aidecoe.name>\r
+Date: Tue, 01 Sep 2015 16:20:47 -0700\r
+Message-ID: <87k2s93ewg.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> <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
+ <878u8rvxap.fsf@ta.scs.stanford.edu> <87613tn45m.fsf@freja.aidecoe.name>\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: Tue, 01 Sep 2015 23:31:08 -0000\r
+\r
+Amadeusz =C5=BBo=C5=82nowski <aidecoe@aidecoe.name> writes:\r
+\r
+> What's more surprising is that there is a test case in notmuch test\r
+> suite which test whether after modifing tag of a mail it is moved from\r
+> new/ to cur/. Yes, it should be moved on any tag modification if I\r
+> understand correctly. But it seems it does not for my maildirs...\r
+>\r
+> $ notmuch search --output=3Dfiles thread:00000000000108bf\r
+> /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000=\r
+FE04I0000000000141A38_0.freja,S=3D53857\r
+> $ notmuch search thread:00000000000108bf\r
+> thread:00000000000108bf  Yest. 11:58 [1/1] Somebody; Subject (reklama unr=\r
+ead)\r
+> $ notmuch tag +hey thread:00000000000108bf\r
+> $ notmuch search thread:00000000000108bf\r
+> thread:00000000000108bf  Yest. 11:58 [1/1] Somebody; Subject (hey reklama=\r
+ unread)\r
+> $ notmuch search --output=3Dfiles thread:00000000000108bf\r
+> /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000=\r
+FE04I0000000000141A38_0.freja,S=3D53857\r
+\r
+First, just to be absolutely sure, doe the file exist?  It's conceivably\r
+that notmuch search is returning stale data until the next time you run\r
+notmuch new.  Not likely, but just trying to rule out all possibilities.\r
+\r
+Second, I wonder if the ",S=3D53857" suffix (size) is throwing things off.\r
+Perhaps libnotmuch only expects suffixes when they are of the form\r
+",S=3D53857:2,<flags>."  Since muchsync does not add a size field (in\r
+either the new or cur subdirectory), it could be leading to the\r
+different behavior.  To test this, can you rename the file in the new\r
+directory without the ",S=3D..." and see if the behavior changes?\r
+\r
+Thanks,\r
+David\r