inotify polling in master branch

Vincent Lefevre vincent at
Mon Jun 11 08:30:27 UTC 2018

On 2018-06-11 10:18:07 +0800, Kevin J. McCarthy wrote:
> On Mon, Jun 11, 2018 at 04:00:55AM +0200, Vincent Lefevre wrote:
> > On 2018-06-11 08:07:22 +0800, Kevin J. McCarthy wrote:
> > > What if instead, we changed the code from a ">" comparison to a "!="
> > > comparison.  This would force a rescan if the mtime were reset backwards:
> > 
> > I'll have to try. But I'm wondering why there is no rescan after one
> > does a sync-mailbox with actual changes: in any case, this may be
> > necessary as new mail could arrive during this time.
> So, in effect, remove the call to maildir_update_mtime() at the end of
> mh_sync_mailbox()?

I've tried again without any change and with debugging support, on
a different machine.I did a first unison. 2 new messages should have
appeared, but debugging showed "mh.c:835: queueing ..." messages,
then "mh.c:880 maildir_add_to_context(): Considering ..." messages.
without these new messages, which did not appear in the mailbox.

I did a second unison. These 2 new messages appeared, but not a newer
one that should have appeared.

I think that there is a race condition with the inotify code: the
inotify event is obtained while the mailbox hasn't been completely
updated, so that one doesn't get the latest messages. What might
happen is that the directory is being updated during the readdir.

Together with other race conditions, things may be worse than what
I'm seeing here.

Vincent Lefèvre <vincent at> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

More information about the Mutt-dev mailing list