Re: [Mutt] #3271: mutt 1.5.20 regression: not updating time fields
#3271: mutt 1.5.20 regression: not updating time fields on mbox
-------------------------------+--------------------------------------------
Reporter: antonio@xxxxxxxx | Owner: pdmef
Type: defect | Status: assigned
Priority: minor | Milestone:
Component: mutt | Version: 1.5.20
Resolution: | Keywords:
-------------------------------+--------------------------------------------
Changes (by pdmef):
* owner: mutt-dev => pdmef
* status: new => assigned
Old description:
> Forwarding from http://bugs.debian.org/533439
>
> {{{When mutt 1.5.20-1 writes changes to an mbox file, it
> changes the file modify time to be the same as the
> access time. This includes just changing the
> message-is-new / message-is-old-but-unread flags.
>
> xbiff reports new mail
> user runs mutt
> xbiff reports new mail a second time
>
> Mutt (including version 1.5.20-1) call utime to set
> the modification time back to the previous value while
> exiting, but in 1.5.20-1 it appears to be modified
> after the call to utime. Running strace without
> tracing children doesn't show a culprit in the main
> process, and running it with children traced makes
> mutt believe that the mbox is read-only (and means
> that flags don't change and the bug isn't reproduced).
> }}}
>
> and the following report from another user:
>
> {{{
> I believe the issue happens with or without xbiff as I have noticed
> mutt says a file has new mail, so I visit it, read the new mails and
> exit mutt. If I launch mutt again, it says the file has new mail
> again, even if all mails have been read.
>
> It is even capable of "confusing itself" in the same session when
> multiple files get mail and I visit one (using change-folder function,
> which suggests unread folders and in order), it will be listed as new
> mail later when I have gone to a second folder, instead of suggesting
> the third folder.
>
> I manually downgraded to 1.5.19-4, which behaves correctly. I use
> relatime mount option, just in case it matters.
> }}}
New description:
Forwarding from http://bugs.debian.org/533439
{{{
When mutt 1.5.20-1 writes changes to an mbox file, it
changes the file modify time to be the same as the
access time. This includes just changing the
message-is-new / message-is-old-but-unread flags.
xbiff reports new mail
user runs mutt
xbiff reports new mail a second time
Mutt (including version 1.5.20-1) call utime to set
the modification time back to the previous value while
exiting, but in 1.5.20-1 it appears to be modified
after the call to utime. Running strace without
tracing children doesn't show a culprit in the main
process, and running it with children traced makes
mutt believe that the mbox is read-only (and means
that flags don't change and the bug isn't reproduced).
}}}
and the following report from another user:
{{{
I believe the issue happens with or without xbiff as I have noticed
mutt says a file has new mail, so I visit it, read the new mails and
exit mutt. If I launch mutt again, it says the file has new mail
again, even if all mails have been read.
It is even capable of "confusing itself" in the same session when
multiple files get mail and I visit one (using change-folder function,
which suggests unread folders and in order), it will be listed as new
mail later when I have gone to a second folder, instead of suggesting
the third folder.
I manually downgraded to 1.5.19-4, which behaves correctly. I use
relatime mount option, just in case it matters.
}}}
--
Comment:
Hmm, I can't reproduce that on OS X and Debian. Can you confirm that
[b080ae086a62] is the problem? How does xbiff detect changes? Just by
comparing mtime vs. atime or does it also cache them for later comparison?
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3271#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent