On Sun, Jun 10, 2018 at 10:33:15AM +0200, Vincent Lefevre wrote: > On 2018-06-09 08:04:21 +0800, Kevin J. McCarthy wrote: > > I've had it on my todo list, but hadn't had a chance to look into it > > yet. Taking a quick peek, the mh_sync_mailbox() code touches the > > context->mtime value using maildir_update_mtime(), and even has a > > comment about a possible race condition. I'm not sure what to do about > > it yet, but perhaps this is what you encountered? > > I'm not sure I understand. If you mean that in some rare occasions, > new mail could fail to be detected, then this is a known issue I had > already seen and reported (bug 3475 in the old BTS), but I had found > that the race condition seemed to be here:
Yes, I believe we are talking about the same thing. New mail arriving
in the middle of a sync may not be noticed.
> Now I'm thinking that there may be a more important new race condition
> due to inotify because files could be looked as soon as they appear,
> and if there is an mtime correction (which occurs here, AFAIK, as I'm
> using unison to retrieve mail and synchronize between various copies
> of my mailboxes), this might confuse Mutt.
This sounds plausible. If mx_check_mailbox() is run immediately, it may
record the st_mtime before it is reset by unison.
What if instead, we changed the code from a ">" comparison to a "!="
comparison. This would force a rescan if the mtime were reset backwards:
/* determine which subdirectories need to be scanned */
if (st_new.st_mtime != ctx->mtime)
changed = 1;
if (st_cur.st_mtime != data->mtime_cur)
changed |= 2;
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
