From 5beb6f362c86899659198047c0a5e224b555753c Mon Sep 17 00:00:00 2001 From: dm-list-email-notmuch Date: Wed, 2 Sep 2015 16:20:47 +1700 Subject: [PATCH] synchronize_flags leaving files in new (was muchsync files renames) --- 4a/1ab625c983e6e6d991a63dcedab29a65b6f69f | 92 +++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 4a/1ab625c983e6e6d991a63dcedab29a65b6f69f diff --git a/4a/1ab625c983e6e6d991a63dcedab29a65b6f69f b/4a/1ab625c983e6e6d991a63dcedab29a65b6f69f new file mode 100644 index 000000000..a0ef97bd6 --- /dev/null +++ b/4a/1ab625c983e6e6d991a63dcedab29a65b6f69f @@ -0,0 +1,92 @@ +Return-Path: + +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id B63E66DE175C + for ; Tue, 1 Sep 2015 16:31:08 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: -1.729 +X-Spam-Level: +X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 + tests=[AWL=-0.085, MISSING_HEADERS=1.207, RCVD_IN_DNSWL_MED=-2.3, + RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001] autolearn=disabled +Received: from arlo.cworth.org ([127.0.0.1]) + by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id q0AZFp7i3r7q for ; + Tue, 1 Sep 2015 16:31:07 -0700 (PDT) +Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) + by arlo.cworth.org (Postfix) with ESMTPS id D156A6DE1329 + for ; Tue, 1 Sep 2015 16:31:06 -0700 (PDT) +Received: from market.scs.stanford.edu (localhost.scs.stanford.edu + [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id + t81NV6nw028693 for ; Tue, 1 Sep 2015 16:31:06 -0700 + (PDT) +Received: (from dm@localhost) + by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t81NV6DU027092; + Tue, 1 Sep 2015 16:31:06 -0700 (PDT) +X-Authentication-Warning: market.scs.stanford.edu: dm set sender to + return-an37y6qdnry79n9gtm96hbshya@ta.scs.stanford.edu using -f +From: dm-list-email-notmuch@scs.stanford.edu +Cc: notmuch@notmuchmail.org +Subject: synchronize_flags leaving files in new (was muchsync files renames) +In-Reply-To: <87613tn45m.fsf@freja.aidecoe.name> +Date: Tue, 01 Sep 2015 16:20:47 -0700 +Message-ID: <87k2s93ewg.fsf@ta.scs.stanford.edu> +References: <878u93ujdo.fsf@freja.aidecoe.name> + <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name> + <87oahxojlv.fsf@ta.scs.stanford.edu> <87vbbwnbb4.fsf@freja.aidecoe.name> + <87io7wr50y.fsf@ta.scs.stanford.edu> <87k2sbmzww.fsf@freja.aidecoe.name> + <87oahnmkqf.fsf@ta.scs.stanford.edu> <87egijm7kw.fsf@freja.aidecoe.name> + <878u8rvxap.fsf@ta.scs.stanford.edu> <87613tn45m.fsf@freja.aidecoe.name> +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.18 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Tue, 01 Sep 2015 23:31:08 -0000 + +Amadeusz =C5=BBo=C5=82nowski writes: + +> What's more surprising is that there is a test case in notmuch test +> suite which test whether after modifing tag of a mail it is moved from +> new/ to cur/. Yes, it should be moved on any tag modification if I +> understand correctly. But it seems it does not for my maildirs... +> +> $ notmuch search --output=3Dfiles thread:00000000000108bf +> /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000= +FE04I0000000000141A38_0.freja,S=3D53857 +> $ notmuch search thread:00000000000108bf +> thread:00000000000108bf Yest. 11:58 [1/1] Somebody; Subject (reklama unr= +ead) +> $ notmuch tag +hey thread:00000000000108bf +> $ notmuch search thread:00000000000108bf +> thread:00000000000108bf Yest. 11:58 [1/1] Somebody; Subject (hey reklama= + unread) +> $ notmuch search --output=3Dfiles thread:00000000000108bf +> /home/aidecoe/Mail/aidecoe/2015/new/1441022521.M714465P23412V000000000000= +FE04I0000000000141A38_0.freja,S=3D53857 + +First, just to be absolutely sure, doe the file exist? It's conceivably +that notmuch search is returning stale data until the next time you run +notmuch new. Not likely, but just trying to rule out all possibilities. + +Second, I wonder if the ",S=3D53857" suffix (size) is throwing things off. +Perhaps libnotmuch only expects suffixes when they are of the form +",S=3D53857:2,." Since muchsync does not add a size field (in +either the new or cur subdirectory), it could be leading to the +different behavior. To test this, can you rename the file in the new +directory without the ",S=3D..." and see if the behavior changes? + +Thanks, +David -- 2.26.2