On Thu, Jul 16, 2020 at 09:03:59AM +0200, Sebastian Stein wrote:
Kevin J. McCarthy <ke...@8t8.us> [200715 08:28]:Have you checked the access time vs modification time of those mailboxes? Capture them before and after procmail, and then launching Mutt. See if this gives any clues.Can you describe the algorithm how to determine if a mbox file has new mails? Is this only done based on timestamps?
There are several configuration variables that can change the behavior ($mail_check_recent, $check_mbox_size). However, by default it's based on access time (Zugriff) vs modification time (Modifiziert).
If the access time is earlier than the modification time, it notifies for new mail.
╰─$ stat Mail/L-file1 Zugriff : 2020-07-16 08:36:57.869739259 +0200 Modifiziert: 2020-07-16 08:36:37.909074114 +0200
╰─$ stat Mail/L-file2 Zugriff : 2020-07-16 08:36:57.805727843 +0200 Modifiziert: 2020-07-16 08:36:37.688061706 +0200
For both L-file1 and L-file2, the access time is *later* than the modification time. So something is reading the files before Mutt even launches.
What happens if other programs access mbox files? For example, what if some Kubuntu desktop search also reads those files?
If they don't reset the access time, this will interfere with new mail detection in mbox files.
So my conclusion would be that just based on those timestamps, mutt can't determine anything. But I guess mutt is keeping it's own last access time somewhere in those .L-file1.index and .L-file.index.ids files.
No, those files aren't owned by mutt.
I've now disabled Kubuntu desktop search, but not sure if this is the cause.
It sounds likely this is the problem. Please let me know if that fixes the problem. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
