{"thread":{"id":"58829","subject":"fsmonitor: t7527 racy on OSX?","startedAt":"2022-11-21T13:28:30Z","lastAt":"2022-11-30T23:28:48Z","messageCount":6,"participants":["Ævar Arnfjörð Bjarmason","Đoàn Trần Công Danh","Eric DeCosta","Jeff Hostetler"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"467684","messageId":"221121.86y1s4bfp6.gmgdl@evledraar.gmail.com","threadId":"58829","inReplyTo":null,"subject":"fsmonitor: t7527 racy on OSX?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-21T13:07:13Z","receivedAt":"2022-11-21T13:28:30Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527 reliably\nfails due to what seems to be a race us doing something, and assuming\nthat fsmonitor picked up on it.\n\nThis makes the tests pass:\n\t\n\tdiff --git a/t/t7527-builtin-fsmonitor.sh b/t/t7527-builtin-fsmonitor.sh\n\tindex 56c0dfffea..ce2555d558 100755\n\t--- a/t/t7527-builtin-fsmonitor.sh\n\t+++ b/t/t7527-builtin-fsmonitor.sh\n\t@@ -428,6 +428,7 @@ test_expect_success 'edit some files' '\n\t \tstart_daemon --tf \"$PWD/.git/trace\" &&\n\t \n\t \tedit_files &&\n\t+\tsleep 1 &&\n\t \n\t \ttest-tool fsmonitor-client query --token 0 &&\n\t \n\t@@ -443,6 +444,7 @@ test_expect_success 'create some files' '\n\t \tstart_daemon --tf \"$PWD/.git/trace\" &&\n\t \n\t \tcreate_files &&\n\t+\tsleep 1 &&\n\t \n\t \ttest-tool fsmonitor-client query --token 0 &&\n\t \n\t@@ -471,6 +473,7 @@ test_expect_success 'rename some files' '\n\t \tstart_daemon --tf \"$PWD/.git/trace\" &&\n\t \n\t \trename_files &&\n\t+\tsleep 1 &&\n\t \n\t \ttest-tool fsmonitor-client query --token 0 &&\n\t \n\t@@ -978,6 +981,7 @@ test_expect_success !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '\n\t \tmkdir test_unicode/nfd/d_${utf8_nfd} &&\n\t \n\t \tgit -C test_unicode fsmonitor--daemon stop &&\n\t+\tsleep 1 &&\n\t \n\t \tif test_have_prereq UNICODE_NFC_PRESERVED\n\t \tthen\n\nThe failure is when we grep out the events we expect, which aren't\nthere, but if you manually inspect them they're there. I.e. they're just\nnot \"in\" yet.\n\nI thought this might be a lack of flushing or syncing in our own trace\ncode, but adding an fsync() to trace_write() didn't do the trick.\n\n1. https://cfarm.tetaneutral.net/news/41#\n"},{"id":"467686","messageId":"Y3t/YbZUIuIJkSil@danh.dev","threadId":"58829","inReplyTo":"221121.86y1s4bfp6.gmgdl@evledraar.gmail.com","subject":"Re: fsmonitor: t7527 racy on OSX?","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2022-11-21T13:38:41Z","receivedAt":"2022-11-21T13:39:42Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2022-11-21 14:07:13+0100, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527 reliably\n> fails due to what seems to be a race us doing something, and assuming\n> that fsmonitor picked up on it.\n\nSee also https://lore.kernel.org/git/YvZbGAf+82WtNXcJ@danh.dev/\n\nI raised 3 months ago and it seems like Jeff Hostetler is too busy.\n\n> \n> This makes the tests pass:\n> \t\n> \tdiff --git a/t/t7527-builtin-fsmonitor.sh b/t/t7527-builtin-fsmonitor.sh\n> \tindex 56c0dfffea..ce2555d558 100755\n> \t--- a/t/t7527-builtin-fsmonitor.sh\n> \t+++ b/t/t7527-builtin-fsmonitor.sh\n> \t@@ -428,6 +428,7 @@ test_expect_success 'edit some files' '\n> \t \tstart_daemon --tf \"$PWD/.git/trace\" &&\n> \t \n> \t \tedit_files &&\n> \t+\tsleep 1 &&\n> \t \n> \t \ttest-tool fsmonitor-client query --token 0 &&\n> \t \n> \t@@ -443,6 +444,7 @@ test_expect_success 'create some files' '\n> \t \tstart_daemon --tf \"$PWD/.git/trace\" &&\n> \t \n> \t \tcreate_files &&\n> \t+\tsleep 1 &&\n> \t \n> \t \ttest-tool fsmonitor-client query --token 0 &&\n> \t \n> \t@@ -471,6 +473,7 @@ test_expect_success 'rename some files' '\n> \t \tstart_daemon --tf \"$PWD/.git/trace\" &&\n> \t \n> \t \trename_files &&\n> \t+\tsleep 1 &&\n> \t \n> \t \ttest-tool fsmonitor-client query --token 0 &&\n> \t \n> \t@@ -978,6 +981,7 @@ test_expect_success !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '\n> \t \tmkdir test_unicode/nfd/d_${utf8_nfd} &&\n> \t \n> \t \tgit -C test_unicode fsmonitor--daemon stop &&\n> \t+\tsleep 1 &&\n> \t \n> \t \tif test_have_prereq UNICODE_NFC_PRESERVED\n> \t \tthen\n> \n> The failure is when we grep out the events we expect, which aren't\n> there, but if you manually inspect them they're there. I.e. they're just\n> not \"in\" yet.\n> \n> I thought this might be a lack of flushing or syncing in our own trace\n> code, but adding an fsync() to trace_write() didn't do the trick.\n> \n> 1. https://cfarm.tetaneutral.net/news/41#\n\n-- \nDanh\n"},{"id":"467775","messageId":"BL0PR05MB55715FF24BD1AD53EE81A5A2D90D9@BL0PR05MB5571.namprd05.prod.outlook.com","threadId":"58829","inReplyTo":"Y3t/YbZUIuIJkSil@danh.dev","subject":"RE: fsmonitor: t7527 racy on OSX?","fromName":"Eric DeCosta","fromEmail":"edecosta@mathworks.com","sentAt":"2022-11-22T17:04:44Z","receivedAt":"2022-11-22T17:12:11Z","isPatch":false,"sender":{"key":"edecosta@mathworks.com","avatar":"https://avatars.githubusercontent.com/u/67609563?v=4"},"body":"\n\n> -----Original Message-----\n> From: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> Sent: Monday, November 21, 2022 8:39 AM\n> To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n> Cc: Git ML <git@vger.kernel.org>; Eric DeCosta\n> <edecosta@mathworks.com>; Jeff Hostetler <jeffhost@microsoft.com>\n> Subject: Re: fsmonitor: t7527 racy on OSX?\n> \n> On 2022-11-21 14:07:13+0100, Ævar Arnfjörð Bjarmason\n> <avarab@gmail.com> wrote:\n> > I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527\n> > reliably fails due to what seems to be a race us doing something, and\n> > assuming that fsmonitor picked up on it.\n> \n> See also https://lore.kernel.org/git/YvZbGAf+82WtNXcJ@danh.dev/\n> <https://protect-\n> us.mimecast.com/s/580RCpYn6ETDOBoycYVkUq?domain=lore.kernel.org>\n> \n> I raised 3 months ago and it seems like Jeff Hostetler is too busy.\n> \n> >\n> > This makes the tests pass:\n> >\n> > diff --git a/t/t7527-builtin-fsmonitor.sh\n> > b/t/t7527-builtin-fsmonitor.sh index 56c0dfffea..ce2555d558 100755\n> > --- a/t/t7527-builtin-fsmonitor.sh\n> > +++ b/t/t7527-builtin-fsmonitor.sh\n> > @@ -428,6 +428,7 @@ test_expect_success 'edit some files' '\n> > start_daemon --tf \"$PWD/.git/trace\" &&\n> >\n> > edit_files &&\n> > + sleep 1 &&\n> >\n> > test-tool fsmonitor-client query --token 0 &&\n> >\n> > @@ -443,6 +444,7 @@ test_expect_success 'create some files' '\n> > start_daemon --tf \"$PWD/.git/trace\" &&\n> >\n> > create_files &&\n> > + sleep 1 &&\n> >\n> > test-tool fsmonitor-client query --token 0 &&\n> >\n> > @@ -471,6 +473,7 @@ test_expect_success 'rename some files' '\n> > start_daemon --tf \"$PWD/.git/trace\" &&\n> >\n> > rename_files &&\n> > + sleep 1 &&\n> >\n> > test-tool fsmonitor-client query --token 0 &&\n> >\n> > @@ -978,6 +981,7 @@ test_expect_success\n> !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '\n> > mkdir test_unicode/nfd/d_${utf8_nfd} &&\n> >\n> > git -C test_unicode fsmonitor--daemon stop &&\n> > + sleep 1 &&\n> >\n> > if test_have_prereq UNICODE_NFC_PRESERVED then\n> >\n> > The failure is when we grep out the events we expect, which aren't\n> > there, but if you manually inspect them they're there. I.e. they're\n> > just not \"in\" yet.\n> >\n> > I thought this might be a lack of flushing or syncing in our own trace\n> > code, but adding an fsync() to trace_write() didn't do the trick.\n> >\n> > 1. https://cfarm.tetaneutral.net/news/41#\n> > <https://protect-\n> us.mimecast.com/s/S6YNCqxoXGIWkoNRHEfMzu?domain=cfarm\n> > .tetaneutral.net>\n> \n> --\n> Danh\n\nHonestly, 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.\n\n-Eric\n"},{"id":"467812","messageId":"BL0PR05MB557192340C68F6771F3962CED90D9@BL0PR05MB5571.namprd05.prod.outlook.com","threadId":"58829","inReplyTo":"BL0PR05MB55715FF24BD1AD53EE81A5A2D90D9@BL0PR05MB5571.namprd05.prod.outlook.com","subject":"RE: fsmonitor: t7527 racy on OSX?","fromName":"Eric DeCosta","fromEmail":"edecosta@mathworks.com","sentAt":"2022-11-22T20:50:46Z","receivedAt":"2022-11-22T20:51:55Z","isPatch":false,"sender":{"key":"edecosta@mathworks.com","avatar":"https://avatars.githubusercontent.com/u/67609563?v=4"},"body":"\n\n> -----Original Message-----\n> From: Eric DeCosta\n> Sent: Tuesday, November 22, 2022 12:05 PM\n> To: Đoàn Trần Công Danh <congdanhqx@gmail.com>; Ævar Arnfjörð\n> Bjarmason <avarab@gmail.com>\n> Cc: Git ML <git@vger.kernel.org>; Jeff Hostetler <jeffhost@microsoft.com>\n> Subject: RE: fsmonitor: t7527 racy on OSX?\n> \n> \n> \n> > -----Original Message-----\n> > From: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> > Sent: Monday, November 21, 2022 8:39 AM\n> > To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n> > Cc: Git ML <git@vger.kernel.org>; Eric DeCosta\n> > <edecosta@mathworks.com>; Jeff Hostetler <jeffhost@microsoft.com>\n> > Subject: Re: fsmonitor: t7527 racy on OSX?\n> >\n> > On 2022-11-21 14:07:13+0100, Ævar Arnfjörð Bjarmason\n> > <avarab@gmail.com> wrote:\n> > > I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527\n> > > reliably fails due to what seems to be a race us doing something,\n> > > and assuming that fsmonitor picked up on it.\n> >\n> > See also https://lore.kernel.org/git/YvZbGAf+82WtNXcJ@danh.dev/\n> > <https://protect-\n> > us.mimecast.com/s/580RCpYn6ETDOBoycYVkUq?domain=lore.kernel.org>\n> >\n> > I raised 3 months ago and it seems like Jeff Hostetler is too busy.\n> >\n> > >\n> > > This makes the tests pass:\n> > >\n> > > diff --git a/t/t7527-builtin-fsmonitor.sh\n> > > b/t/t7527-builtin-fsmonitor.sh index 56c0dfffea..ce2555d558 100755\n> > > --- a/t/t7527-builtin-fsmonitor.sh\n> > > +++ b/t/t7527-builtin-fsmonitor.sh\n> > > @@ -428,6 +428,7 @@ test_expect_success 'edit some files' '\n> > > start_daemon --tf \"$PWD/.git/trace\" &&\n> > >\n> > > edit_files &&\n> > > + sleep 1 &&\n> > >\n> > > test-tool fsmonitor-client query --token 0 &&\n> > >\n> > > @@ -443,6 +444,7 @@ test_expect_success 'create some files' '\n> > > start_daemon --tf \"$PWD/.git/trace\" &&\n> > >\n> > > create_files &&\n> > > + sleep 1 &&\n> > >\n> > > test-tool fsmonitor-client query --token 0 &&\n> > >\n> > > @@ -471,6 +473,7 @@ test_expect_success 'rename some files' '\n> > > start_daemon --tf \"$PWD/.git/trace\" &&\n> > >\n> > > rename_files &&\n> > > + sleep 1 &&\n> > >\n> > > test-tool fsmonitor-client query --token 0 &&\n> > >\n> > > @@ -978,6 +981,7 @@ test_expect_success\n> > !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '\n> > > mkdir test_unicode/nfd/d_${utf8_nfd} &&\n> > >\n> > > git -C test_unicode fsmonitor--daemon stop &&\n> > > + sleep 1 &&\n> > >\n> > > if test_have_prereq UNICODE_NFC_PRESERVED then\n> > >\n> > > The failure is when we grep out the events we expect, which aren't\n> > > there, but if you manually inspect them they're there. I.e. they're\n> > > just not \"in\" yet.\n> > >\n> > > I thought this might be a lack of flushing or syncing in our own\n> > > trace code, but adding an fsync() to trace_write() didn't do the trick.\n> > >\n> > > 1. https://cfarm.tetaneutral.net/news/41#\n> > > <https://protect-\n> > us.mimecast.com/s/S6YNCqxoXGIWkoNRHEfMzu?domain=cfarm\n> > > .tetaneutral.net>\n> >\n> > --\n> > Danh\n> \n> Honestly, I'm not surprised. Stopping the daemon and grepping for expected\n> results immediately there after is just asking for these sorts of races.\n> Sleeping is a bit ugly, but without an explicit means of synchronization is\n> probably the best that can be done. I can take a look at it some more as I\n> have access to M1 Macs.\n> \n> -Eric\n\nhttps://github.com/gitgitgadget/git/commit/63db616d0ec644cee9f81529ed093beee0a01f65\n\nAfter applying those pending test changes that I have been developing for fsmonitor for Linux, I have been unable to reproduce the problem on Mac OS.\n\n-Eric\n"},{"id":"467817","messageId":"221122.86r0xuaawz.gmgdl@evledraar.gmail.com","threadId":"58829","inReplyTo":"BL0PR05MB55715FF24BD1AD53EE81A5A2D90D9@BL0PR05MB5571.namprd05.prod.outlook.com","subject":"Re: fsmonitor: t7527 racy on OSX?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-22T22:12:20Z","receivedAt":"2022-11-22T22:20:53Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Nov 22 2022, Eric DeCosta wrote:\n\n>> -----Original Message-----\n>> From: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n>> Sent: Monday, November 21, 2022 8:39 AM\n>> To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>> Cc: Git ML <git@vger.kernel.org>; Eric DeCosta\n>> <edecosta@mathworks.com>; Jeff Hostetler <jeffhost@microsoft.com>\n>> Subject: Re: fsmonitor: t7527 racy on OSX?\n>> \n>> On 2022-11-21 14:07:13+0100, Ævar Arnfjörð Bjarmason\n>> <avarab@gmail.com> wrote:\n>> > I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527\n>> > reliably fails due to what seems to be a race us doing something, and\n>> > assuming that fsmonitor picked up on it.\n>> \n>> See also https://lore.kernel.org/git/YvZbGAf+82WtNXcJ@danh.dev/\n>> <https://protect-\n>> us.mimecast.com/s/580RCpYn6ETDOBoycYVkUq?domain=lore.kernel.org>\n>> \n>> I raised 3 months ago and it seems like Jeff Hostetler is too busy.\n>> \n>> >\n>> > This makes the tests pass:\n>> >\n>> > diff --git a/t/t7527-builtin-fsmonitor.sh\n>> > b/t/t7527-builtin-fsmonitor.sh index 56c0dfffea..ce2555d558 100755\n>> > --- a/t/t7527-builtin-fsmonitor.sh\n>> > +++ b/t/t7527-builtin-fsmonitor.sh\n>> > @@ -428,6 +428,7 @@ test_expect_success 'edit some files' '\n>> > start_daemon --tf \"$PWD/.git/trace\" &&\n>> >\n>> > edit_files &&\n>> > + sleep 1 &&\n>> >\n>> > test-tool fsmonitor-client query --token 0 &&\n>> >\n>> > @@ -443,6 +444,7 @@ test_expect_success 'create some files' '\n>> > start_daemon --tf \"$PWD/.git/trace\" &&\n>> >\n>> > create_files &&\n>> > + sleep 1 &&\n>> >\n>> > test-tool fsmonitor-client query --token 0 &&\n>> >\n>> > @@ -471,6 +473,7 @@ test_expect_success 'rename some files' '\n>> > start_daemon --tf \"$PWD/.git/trace\" &&\n>> >\n>> > rename_files &&\n>> > + sleep 1 &&\n>> >\n>> > test-tool fsmonitor-client query --token 0 &&\n>> >\n>> > @@ -978,6 +981,7 @@ test_expect_success\n>> !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '\n>> > mkdir test_unicode/nfd/d_${utf8_nfd} &&\n>> >\n>> > git -C test_unicode fsmonitor--daemon stop &&\n>> > + sleep 1 &&\n>> >\n>> > if test_have_prereq UNICODE_NFC_PRESERVED then\n>> >\n>> > The failure is when we grep out the events we expect, which aren't\n>> > there, but if you manually inspect them they're there. I.e. they're\n>> > just not \"in\" yet.\n>> >\n>> > I thought this might be a lack of flushing or syncing in our own trace\n>> > code, but adding an fsync() to trace_write() didn't do the trick.\n>> >\n>> > 1. https://cfarm.tetaneutral.net/news/41#\n>> > <https://protect-\n>> us.mimecast.com/s/S6YNCqxoXGIWkoNRHEfMzu?domain=cfarm\n>> > .tetaneutral.net>\n>> \n>> --\n>> Danh\n>\n> Honestly, I'm not surprised. Stopping the daemon and grepping for\n> expected results immediately there after is just asking for these\n> sorts of races. Sleeping is a bit ugly, but without an explicit means\n> of synchronization is probably the best that can be done. I can take a\n> look at it some more as I have access to M1 Macs.\n\nI don't see why it would have to do with stopping the daemon. If\nanything that should reduce the odds that you're running into a\nrace. I.e. on OSX in general this will work:\n\n\techo foo >f &&\n\tgrep foo f\n\nOr, the equivalent with an \"echo\" that's not a shell built-in. I.e. we\nhad a process start, print to a file, and then we grep data out of it\nagin.\n\nThe reason I'm saying it should reduce them is if the \"echo\" were some\nlong-running daemon process that was still running the \"grep\" might fail\nbecause the \"foo\" was still in some buffer and hadn't been written or\nfsync'd to disk.\n\nAnyway, all of that seems inapplicable to these failures, as we're not\nstopping the daemon yet by the time we run into the synchronization\nproblem. We just *started* it, then renamed some files, but when we ask\nfor those events we don't get them back.\n\nMaybe there's some innocuous reason for that, but I have the sinking\nfeeling that it might be some race between creating the files, the\nkernel getting those events, acting on them, but not having sent notice\nof those events to the daemon that's listening.\n\n*That* would be much scarier, and would mean that this fsmonitor\nimplementation would be racy outside of our tests, wouldn't it?\n"},{"id":"468293","messageId":"d9160bf2-4bce-2624-c80d-fd924e014f70@jeffhostetler.com","threadId":"58829","inReplyTo":"221122.86r0xuaawz.gmgdl@evledraar.gmail.com","subject":"Re: fsmonitor: t7527 racy on OSX?","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2022-11-30T23:18:27Z","receivedAt":"2022-11-30T23:28:48Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 11/22/22 5:12 PM, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, Nov 22 2022, Eric DeCosta wrote:\n> \n>>> -----Original Message-----\n>>> From: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n>>> Sent: Monday, November 21, 2022 8:39 AM\n>>> To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>> Cc: Git ML <git@vger.kernel.org>; Eric DeCosta\n>>> <edecosta@mathworks.com>; Jeff Hostetler <jeffhost@microsoft.com>\n>>> Subject: Re: fsmonitor: t7527 racy on OSX?\n>>>\n>>> On 2022-11-21 14:07:13+0100, Ævar Arnfjörð Bjarmason\n>>> <avarab@gmail.com> wrote:\n>>>> I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527\n>>>> reliably fails due to what seems to be a race us doing something, and\n>>>> assuming that fsmonitor picked up on it.\n>>>\n>>> See also https://lore.kernel.org/git/YvZbGAf+82WtNXcJ@danh.dev/\n>>> <https://protect-\n>>> us.mimecast.com/s/580RCpYn6ETDOBoycYVkUq?domain=lore.kernel.org>\n>>>\n>>> I raised 3 months ago and it seems like Jeff Hostetler is too busy.\n>>>\n>>>>\n>>>> This makes the tests pass:\n>>>>\n>>>> diff --git a/t/t7527-builtin-fsmonitor.sh\n>>>> b/t/t7527-builtin-fsmonitor.sh index 56c0dfffea..ce2555d558 100755\n>>>> --- a/t/t7527-builtin-fsmonitor.sh\n>>>> +++ b/t/t7527-builtin-fsmonitor.sh\n>>>> @@ -428,6 +428,7 @@ test_expect_success 'edit some files' '\n>>>> start_daemon --tf \"$PWD/.git/trace\" &&\n>>>>\n>>>> edit_files &&\n>>>> + sleep 1 &&\n>>>>\n>>>> test-tool fsmonitor-client query --token 0 &&\n>>>>\n>>>> @@ -443,6 +444,7 @@ test_expect_success 'create some files' '\n>>>> start_daemon --tf \"$PWD/.git/trace\" &&\n>>>>\n>>>> create_files &&\n>>>> + sleep 1 &&\n>>>>\n>>>> test-tool fsmonitor-client query --token 0 &&\n>>>>\n>>>> @@ -471,6 +473,7 @@ test_expect_success 'rename some files' '\n>>>> start_daemon --tf \"$PWD/.git/trace\" &&\n>>>>\n>>>> rename_files &&\n>>>> + sleep 1 &&\n>>>>\n>>>> test-tool fsmonitor-client query --token 0 &&\n>>>>\n>>>> @@ -978,6 +981,7 @@ test_expect_success\n>>> !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '\n>>>> mkdir test_unicode/nfd/d_${utf8_nfd} &&\n>>>>\n>>>> git -C test_unicode fsmonitor--daemon stop &&\n>>>> + sleep 1 &&\n>>>>\n>>>> if test_have_prereq UNICODE_NFC_PRESERVED then\n>>>>\n>>>> The failure is when we grep out the events we expect, which aren't\n>>>> there, but if you manually inspect them they're there. I.e. they're\n>>>> just not \"in\" yet.\n>>>>\n>>>> I thought this might be a lack of flushing or syncing in our own trace\n>>>> code, but adding an fsync() to trace_write() didn't do the trick.\n>>>>\n>>>> 1. https://cfarm.tetaneutral.net/news/41#\n>>>> <https://protect-\n>>> us.mimecast.com/s/S6YNCqxoXGIWkoNRHEfMzu?domain=cfarm\n>>>> .tetaneutral.net>\n>>>\n>>> --\n>>> Danh\n>>\n>> Honestly, I'm not surprised. Stopping the daemon and grepping for\n>> expected results immediately there after is just asking for these\n>> sorts of races. Sleeping is a bit ugly, but without an explicit means\n>> of synchronization is probably the best that can be done. I can take a\n>> look at it some more as I have access to M1 Macs.\n> \n> I don't see why it would have to do with stopping the daemon. If\n> anything that should reduce the odds that you're running into a\n> race. I.e. on OSX in general this will work:\n> \n> \techo foo >f &&\n> \tgrep foo f\n> \n> Or, the equivalent with an \"echo\" that's not a shell built-in. I.e. we\n> had a process start, print to a file, and then we grep data out of it\n> agin.\n> \n> The reason I'm saying it should reduce them is if the \"echo\" were some\n> long-running daemon process that was still running the \"grep\" might fail\n> because the \"foo\" was still in some buffer and hadn't been written or\n> fsync'd to disk.\n> \n> Anyway, all of that seems inapplicable to these failures, as we're not\n> stopping the daemon yet by the time we run into the synchronization\n> problem. We just *started* it, then renamed some files, but when we ask\n> for those events we don't get them back.\n> \n> Maybe there's some innocuous reason for that, but I have the sinking\n> feeling that it might be some race between creating the files, the\n> kernel getting those events, acting on them, but not having sent notice\n> of those events to the daemon that's listening.\n> \n> *That* would be much scarier, and would mean that this fsmonitor\n> implementation would be racy outside of our tests, wouldn't it?\n\nI managed to reliably reproduce this on my new M1 mac (and while\nworking on replacing the call to the deprecated FSEvents routine\nmentioned in another thread).\n\nI should have a fix for this/them shortly.\n\nThanks for your patience.\nJeff\n\n"}]}