> -----Original Message----- > From: Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> > Sent: Monday, November 21, 2022 8:39 AM > To: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> > Cc: Git ML <git@xxxxxxxxxxxxxxx>; Eric DeCosta > <edecosta@xxxxxxxxxxxxx>; Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> > Subject: Re: fsmonitor: t7527 racy on OSX? > > On 2022-11-21 14:07:13+0100, Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> 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@xxxxxxxx/ > <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 Honestly, I'm not surprised. Stopping the daemon and grepping for expected results immediately there after is just asking for these sorts of races. Sleeping is a bit ugly, but without an explicit means of synchronization is probably the best that can be done. I can take a look at it some more as I have access to M1 Macs. -Eric
