Package: trn4 Version: 4.0-test77-13 Severity: minor trn4 has a feature where it can tell you if there's new mail in your local mailbox (/var/mail/$USER or whatever), by putting "(Mail)" in the status line, e.g. (Mail) -- Select a newsgroup (natural order) (See MAILCALL and MAILFILE in the man page for a mention of this behaviour, although I have neither of these environment variables set.)
I'm finding that this sometimes fires spuriously -- I have no unread mail, and yet the "(Mail)" indicator appears in trn4, and persists until something changes in my mailbox -- I can make it go away by making and committing a trivial change to my mailbox file. I noticed this occasionally on jessie (trn4 4.0-test77-11), but it seems much more frequent for me (annoyingly so) on bullseye (4.0-test77-13). I have half a theory about what's going on: Here's the logic that trn4 uses to check for new mail (in general, code about it is protected by "#ifdef MAILCALL"): <https://salsa.debian.org/debian/trn4/-/blob/master/ng.c#L1605> if (stat(mailfile,&filestat) < 0 || !filestat.st_size || filestat.st_atime > filestat.st_mtime) /* don't flag new mail */ else /* flag new mail */ So, that can flag new mail if the mailbox atime == mtime (to a whole number of seconds), which seems like a thing that could happen if the MUA is very on the ball about checking the mailbox file. My MUA is mutt (run on the same machine as trn4). Between jessie (1.5.23-3+deb8u6) and bullseye (2.0.5-4.1), mutt started using inotify to watch mailboxes (1.11.0, "inotify is used for local mailbox monitoring on Linux"). So it seems plausible that the condition above could happen more often these days; if the mutt process is active, it could plausibly access the mailbox in the same second that new mail arrives. In at least one instance where I've reproduced this trn4 behaviour by sending myself mail, the timestamps seemed to support my theory: $ stat /var/spool/mail/jacobn ... Access: 2022-08-12 17:25:57.799257318 +0100 Modify: 2022-08-12 17:25:57.000000000 +0100 Change: 2022-08-12 17:25:57.799257318 +0100 Birth: 1970-01-01 01:00:00.000000000 +0100 I haven't thought too hard about how this theory interacts with me, the human, actually reading the mail in my MUA, updating the status flags, and committing them to the mailbox file. I haven't thought hard about what the correct fix would be, either. Obviously it's tempting to change > to >=, but I don't know if that's completely safe. Comparing to bash's mailcheck.c as another implementation of this sort of feature (which doesn't cause me trouble), I find that it's much more stateful (remembering previous mtimes etc), but at its heart is a similar-looking check, which treats atime==mtime as *not* a cause for new mail: https://git.savannah.gnu.org/cgit/bash.git/tree/mailcheck.c#n463 (I think bash is only looking at second-granularity timestamps, same as trn4.) (I'm raising this as much to record my investigations as in the hope it will be fixed. I haven't reported it upstream. If it annoys me too much I'll probably just turn off the feature.)
