muchsync files renames

[Amadeusz Żołnowski]

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,

-- 
Amadeusz Żołnowski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 950 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20150831/e2190c27/attachment.sig>