Several of the FileSystemWatcherTests are failing after PR 14043

[tannergooding]

It seems that dotnet/coreclr#14043 introduced four failures in the CoreFX baseline tests:

• System.IO.Tests.File_Create_Tests.FileSystemWatcher_File_Create
• System.IO.Tests.FileSystemWatcherTests_netstandard17.EndInit_ResumesPausedEnableRaisingEvents
• System.IO.Tests.FileSystemWatcherTests_netstandard17.EndInit_ResumesPausedEnableRaisingEvents(setBeforeBeginInit: True)
• System.IO.Tests.FileSystemWatcherTests_netstandard17.EndInit_ResumesPausedEnableRaisingEvents(setBeforeBeginInit: False)

These were first detected in dotnet/coreclr#14119 (Job: https://ci.dot.net/job/dotnet_coreclr/job/master/job/jitstress/job/x64_checked_ubuntu_corefx_baseline_prtest/98/). But they also appeared earlier in the daily runs of the job: https://ci.dot.net/job/dotnet_coreclr/job/master/job/jitstress/job/x64_checked_ubuntu_corefx_baseline/298/.

NOTE: It wasn't detected earlier due to other build failures in the job that was caused by an unrelated change.

I did validate that it repro's as of the PR commit (555f436), but not in the commit prior to that (5d37885).

[tannergooding]

FYI. @stephentoub, @pjanotti, @JeremyKuhne, since you were the reviewers and/or tagged for review on the associated PR.

[poizan42]

The ftruncate call fires a MODIFY inotify event (even on an empty file). I think the solutions are:

1. Make ExpectEvent/ExecuteAndVerifyEvents more tolerant of "spurious" events like on OSX.
2. A limited version of 1. - add an argument to ExpectEvent to tell it that an event is allowed but not required.
3. Make the tests use CreateNew or OpenOrCreate rather than Create
4. Check whether the file is empty before truncating

Option 4. incurs an overhead of an extra syscall. Option 3. is complicated by the fact that the tests in tests/FileSystemWatcher.cs creates the file through TempFile which in turn calls File.WriteAllBytes.

[pjanotti]

Thanks @tannergooding.

@poizan42 at first glance I agree: either solution 1 or 2, initially I am leaning towards 1.

[jkotas]

@pjanotti @poizan42 Could you please get this fixed, or get the test disabled in the meantime? People are hitting it in CI.

[pjanotti]

/cc @jkotas

Marked failed tests as active issues: dotnet/corefx#24305

[poizan42]

@pjanotti @stephentoub I can make a PR, but first I would like to know which of the solutions to go with. The strict verification on non-OSX ensures that backwards compatibility is kept at least per-platform, even though user programs probably shouldn't rely on that. But of course dotnet/coreclr#14043 already did change the behaviour so it could break badly written programs.

[pjanotti]

Thanks @poizan42. The less strict verification makes more sense to me, making it very strict means that we risk to have to adapt whenever a new platform comes onboard and the adaptation is to "correct" the test.

[pjanotti]

Hi @poizan42 do you have time to work on this? If yes I can assign it to you, if not, (of course) it is fine, I can take a look at it.

[poizan42]

@pjanotti You can assign me :)

[pjanotti]

Thanks. I discovered that I can't actually assign the issue to you. Your name/alias doesn't show on the set of possible assignees.

@karelz is @poizan42 missing some step/approval in order to be assigned stuff to him on coreclr?

[poizan42]

@pjanotti That's because I'm only a Collaborator on corefx and not coreclr, I believe @karelz can fix that

[pjanotti]

Ah, that makes sense. So let's do that on your next contribution to coreclr.

[karelz]

@poizan42 yes, fixed - check your inbox for the invitation.
Pro tip: Disable notifications on the repo, just enable those where you are mentioned, otherwise you will drown in notifications ;)