From bc4f0e333201bed4f124560419f73bca834acb73 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Amadeusz=20=C5=BBo=C5=82nowski?= Date: Mon, 31 Aug 2015 12:59:43 +0100 Subject: [PATCH] Re: muchsync files renames --- 9d/0b97b0b5ca0f43b523662b800daa17741468b5 | 167 ++++++++++++++++++++++ 1 file changed, 167 insertions(+) create mode 100644 9d/0b97b0b5ca0f43b523662b800daa17741468b5 diff --git a/9d/0b97b0b5ca0f43b523662b800daa17741468b5 b/9d/0b97b0b5ca0f43b523662b800daa17741468b5 new file mode 100644 index 000000000..a84fac8ae --- /dev/null +++ b/9d/0b97b0b5ca0f43b523662b800daa17741468b5 @@ -0,0 +1,167 @@ +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 41EC36DE0173 + for ; Mon, 31 Aug 2015 05:00:09 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: -0.004 +X-Spam-Level: +X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=0.097, + DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3958G_EQJy6N for ; + Mon, 31 Aug 2015 05:00:03 -0700 (PDT) +Received: from jim.zolnowski.name (jim.zolnowski.name [188.116.54.122]) + by arlo.cworth.org (Postfix) with ESMTPS id DB2506DE00CB + for ; Mon, 31 Aug 2015 05:00:02 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; + d=aidecoe.name; s=jim; + h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=9Ge6koUgJvpMRIXm5sL2Rt4A44TAHkJmCGhcaWYBWzk=; + b=jZwuatiOIs8cjhDp8vpUg+XN1CxE6l+jymfyISXODSc6KGW4366s0mJcuLQrqROKzTozteGIE9g/1oKaonCBI0khy6RzQ4QAFR19dJ0kXkjXIUHZK3a08CumvZnJMaShvKRJbP8N1tjns7s8tiX+zocvzAn7LYQLKTgezWDL19BOqGicTEq7wrrGA3Y91hrsz5kBG14/7yyCNNS8Hjtf/oOPkj59TcAyS6DZiZNCD5/+zz9QmLUGFYp4V36x8bn30wMaPWp/q+nx6E2vBdNnMgzZXGA++m3TmSbjcFHKJrvfLofvokakkCxVCWyeN0165776LK11Yr44qu1TiCC5Xw==; +Received: from cpc3-cmbg17-2-0-cust294.5-4.cable.virginm.net ([86.22.65.39] + helo=localhost) + by jim.zolnowski.name with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) + (Exim 4.85) (envelope-from ) + id 1ZWNki-0002yd-3C; Mon, 31 Aug 2015 13:59:58 +0200 +From: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= +To: David Mazieres expires 2015-11-28 PST + +Subject: Re: muchsync files renames +In-Reply-To: <87io7wr50y.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> +User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 + (x86_64-pc-linux-gnu) +Date: Mon, 31 Aug 2015 12:59:43 +0100 +Message-ID: <87k2sbmzww.fsf@freja.aidecoe.name> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha512; protocol="application/pgp-signature" +Cc: notmuch@notmuchmail.org +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: Mon, 31 Aug 2015 12:00:09 -0000 + +--=-=-= +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable + +Hi David, + +First of all thank you a lot for support. I am Cc'ing ml because the +last paragraph may be useful hint for other users. + + +David Mazieres writes: +> So to be clear, you are getting tons of lines that start "[SERVER] +> [notmuch]" and contain the string "Ignoring non-mail file"? Is the +> "##...##" literal, or is that an ellipsis? + +I have just cut off few directories on the path. :-) All of these files +are invalid spam mail, indeed. I have removed them. One problem less. + + +> Also, those file names were not generated were not generated by +> muchsync. Any mail file created by muchsync will have a file name of +> the form: +> +> nnn.MnnnPnnnQnRn.machine +> nnn.MnnnPnnnQnRn.machine:2, + +Just to makes things clear (once again? :-)), these file names are +generated only on client side. Muchsync is not gonna ever to sync file +names to server, is it? + + +> When you run "notmuch new" on the server, without muchsync, does it +> take forever and print all these message while scanning non mail +> files? + +No. Notmuch doesn't print these messages when I just run "notmuch new" +myself. Anyway there was only around 100 of invalid mail files. + + +> Okay, this is the interesting part. It appears that 5775 out of your +> 115877 messages have been moved to a different directory on the +> client. I notice that the one message you include above has been +> moved to the Spam maildir. + +> Is it possible that A) you have some spam filtering on the client that +> is moving things to the Spam folder, + +I have a mailfilter rule which moves mails with "X-Spam-Status: Yes" to +Spam directory, but this happens on delivery before notmuch indexing. + + +> or B) that one of your two machines is using a case-independent file +> system that is causing confusion between "Spam" and "spam"? + +I am testing it on single GNU/Linux host between different users. It is +ext4 fs. + + +> So... based on all the evidence so fare the culprit seems to be that +> something is moving mail files into your Spam folder on the client. +> If that rings any bells and solves the problem, great. If not, here +> is what we need to do to track it down further. + +I have followed you hints to track down the issue. All of these +messages are spam. What I suspect follows. + +All of these files have been placed to new/ subdir by maildrop and +during posthook (afew) have been stripped of any tags besides 'spam' +tag, in particular 'unread' tag has been removed, but files still remain +in new/ subdir. So... what had to happen is that during muchsync these +messages have been discovered as already read, so they don't belong to +new/ but must be moved to cur/. And this is what happened on client +side. During next muchsync these changes had to be pushed to server, +i.e. move from new/ to cur/. + +So if my assumptions are correct, actually there is no issue! I would +just have to adjust afew filtering to prevent this behaviour. + + +Thank you, + +=2D-=20 +Amadeusz =C5=BBo=C5=82nowski + +--=-=-= +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2.1 + +iQJ8BAEBCgBmBQJV5EGwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCMzcyRTFENjI5NUM1MzYwQTQwODQyRUZD +QkNDODAyM0Y1OUUxNzA0AAoJEMvMgCP1nhcEzOEP/1HNI56B+1hy5XTb/IhXDCUj ++k/AbdFDhBb+kHxNTly9F+qjBt8hSTZhUC3FojqVWBgVMGKarqyQ6+pV8YcbRWJK +HCaiWzvi4miXMFYvDtjVKzkTsZS6vXfzmSX4WrrXkHzkF5a/M7bY736xvBVTXoO1 +jzbXkjsIJcyXSztpead8thrTCM4iWozxJ8+H/ZvJNtgV0ch68l3J8jXI7YL1OQyn +esYhs9NyGVxAaQyrvERs7HClAtZg25iGi0hX5ZbH+y4Oy41XXQz2QlyX/us04AC/ +1SjzeNW5/rBPxPRtO4baHuiLvwQGa4pIHIKxssn6uvi8tW//vPo95zGa4nhLf5Q1 +D9Pe3e6dmOP9wlzaIAOSboSus/WlomcvfjWs8dGHeNtbk9ZxwN7j0U37J9j33vgS +8hHCxUaaJEXckDPL78q6x3IPZMgpNdhH7+yZFUf34KwK5F44aIi0WEsuUCuh2LLW +jkp/BdERhX6+wgsrFrsK1c2gXB/zLGcBjoSCKJfzvL/WvFn6vW6ehaFI1EAsdgJK +jgemkP2ZuXjp5ocBlNKaVWQfVs+XPWfBWr22c+OG4BbRG8g43AG3xNt7i3oZlblZ +sLAdlP0ABCU2qp/nSed3vdwPCLv4uZc03FU2VuX1BaEa7YcN4b2NMRbvsy7oi/k0 +ywAyTsVOxpO/9a85jVA4 +=EMSP +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2