inotify polling in master branch

Vincent Lefevre vincent at vinc17.org
Mon Jun 11 09:28:09 UTC 2018


On 2018-06-11 10:30:27 +0200, Vincent Lefevre wrote:
> 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:

This doesn't have any effect.

> > > 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()?

This doesn't have any effect either.

> 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.

So I think that this is the real issue. But there may be other ones.

static void maildir_update_mtime (CONTEXT * ctx)
{
  char buf[_POSIX_PATH_MAX];
  struct stat st;
  struct mh_data *data = mh_data (ctx);

  if (ctx->magic == MUTT_MAILDIR)
  {
    snprintf (buf, sizeof (buf), "%s/%s", ctx->path, "cur");
    if (stat (buf, &st) == 0)
      data->mtime_cur = st.st_mtime;
    snprintf (buf, sizeof (buf), "%s/%s", ctx->path, "new");
  }
[...]

Isn't this a race condition? New mail could have been received before
the call to maildir_update_mtime (starting with opendir) and the
"stat". The recorded mtime should be one obtained before the opendir
in order to make sure not to miss any new message. But this is not
sufficient. But should parse the directory only when the current time
is strictly larger than the recorded mtime.

I think that with network file systems (such as NFS), this may not
even be sufficient if there is a shift between the times of the client
and the server. A solution may be to force a reparse of the directory
a few seconds after the mtime has last changed.

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


More information about the Mutt-dev mailing list