inotify polling in master branch

[Kevin J. McCarthy]

On Mon, Jun 11, 2018 at 11:28:09AM +0200, Vincent Lefevre wrote:
> 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.

The maildir_check_mailbox() performs a stat first, then scans for new
mail.  How is it that the messages are added during/after the scan but
the directory mtime doesn't change?  If unison were resetting mtime, it
shouldn't be to the time when we scanned but didn't find all the
messages.

> > > So, in effect, remove the call to maildir_update_mtime() at the end of
> > > mh_sync_mailbox()?
> 
> This doesn't have any effect either.

This was for a different issue: the sync-mailbox race condition which I
believe is separate from the new mail detection issue you are seeing
with inotify.

> static void maildir_update_mtime (CONTEXT * ctx)
> [...]
> 
> 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".

This is called only during the initial mailbox open and when performing
a sync, so I believe is also a separate issue.  Let's focus on the
main unison check-mailbox issue for now until I can make sense of it.

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180611/20e0961a/attachment.asc>