RE: fsmonitor: t7527 racy on OSX?

> -----Original Message-----
> From: Đoàn Trần Công Danh <congdanhqx@gmail.com>
> Sent: Monday, November 21, 2022 8:39 AM
> To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Cc: Git ML <git@vger.kernel.org>; Eric DeCosta
> <edecosta@mathworks.com>; Jeff Hostetler <jeffhost@microsoft.com>
> Subject: Re: fsmonitor: t7527 racy on OSX?
> 
> On 2022-11-21 14:07:13+0100, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
> > I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527
> > reliably fails due to what seems to be a race us doing something, and
> > assuming that fsmonitor picked up on it.
> 
> See also https://lore.kernel.org/git/YvZbGAf+82WtNXcJ@danh.dev/
> <https://protect-
> us.mimecast.com/s/580RCpYn6ETDOBoycYVkUq?domain=lore.kernel.org>
> 
> I raised 3 months ago and it seems like Jeff Hostetler is too busy.
> 
> >
> > This makes the tests pass:
> >
> > diff --git a/t/t7527-builtin-fsmonitor.sh
> > b/t/t7527-builtin-fsmonitor.sh index 56c0dfffea..ce2555d558 100755
> > --- a/t/t7527-builtin-fsmonitor.sh
> > +++ b/t/t7527-builtin-fsmonitor.sh
> > @@ -428,6 +428,7 @@ test_expect_success 'edit some files' '
> > start_daemon --tf "$PWD/.git/trace" &&
> >
> > edit_files &&
> > + sleep 1 &&
> >
> > test-tool fsmonitor-client query --token 0 &&
> >
> > @@ -443,6 +444,7 @@ test_expect_success 'create some files' '
> > start_daemon --tf "$PWD/.git/trace" &&
> >
> > create_files &&
> > + sleep 1 &&
> >
> > test-tool fsmonitor-client query --token 0 &&
> >
> > @@ -471,6 +473,7 @@ test_expect_success 'rename some files' '
> > start_daemon --tf "$PWD/.git/trace" &&
> >
> > rename_files &&
> > + sleep 1 &&
> >
> > test-tool fsmonitor-client query --token 0 &&
> >
> > @@ -978,6 +981,7 @@ test_expect_success
> !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '
> > mkdir test_unicode/nfd/d_${utf8_nfd} &&
> >
> > git -C test_unicode fsmonitor--daemon stop &&
> > + sleep 1 &&
> >
> > if test_have_prereq UNICODE_NFC_PRESERVED then
> >
> > The failure is when we grep out the events we expect, which aren't
> > there, but if you manually inspect them they're there. I.e. they're
> > just not "in" yet.
> >
> > I thought this might be a lack of flushing or syncing in our own trace
> > code, but adding an fsync() to trace_write() didn't do the trick.
> >
> > 1. https://cfarm.tetaneutral.net/news/41#
> > <https://protect-
> us.mimecast.com/s/S6YNCqxoXGIWkoNRHEfMzu?domain=cfarm
> > .tetaneutral.net>
> 
> --
> Danh