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
signature.asc
Description: PGP signature
