From: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= <aidecoe@aidecoe.name>
To: David Mazieres expires 2015-11-28 PST
 <mazieres-evmnkzzavjvnrbsbughkgbywbs@temporary-address.scs.stanford.edu>
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
Precedence: list

--=-=-=
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-----
--=-=-=--