Make PhysicalFileProvider polling more resilient to IO exceptions

[jozkee]

Fixes #71003
Fixes #56810

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-filesystem
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #71003
Fixes #56810

Author:	Jozkee
Assignees:	Jozkee
Labels:	area-Extensions-FileSystem
Milestone:	7.0.0

[danmoseley]

Should we catch any exception that could be IO related? Or is the API we are calling only going to throw these two?

Reasoning: the app has little or no control over whether examining arbitrary files on disk leads to an IO exception. It could be a corrupted disk, for a start. The app can't filter these out and can't catch them - it will just terminate. Is that a better experience than catching them?

If we catch all IO exceptions, you can use this as a guide:
https://github.com/dotnet/msbuild/blob/c34eb484f1ddf0f9e1940c620b1eff169433f5a1/src/Shared/ExceptionHandling.cs#L130-L145

[jozkee]

I'm certain the API won't throw these ones:

e is NotSupportedException
|| (e is ArgumentException && !(e is ArgumentNullException))
|| e is SecurityException

All exceptions come form Win32Marshal.GetExceptionForWin32Error. which can return Unauthorized, several exceptions derived from IOException, and OperationCanceledException, which I don't think happens for this case.
https://source.dot.net/#System.Private.CoreLib/Win32Marshal.cs,8cf456a56c1e487e

[danmoseley]

sounds good to me.

[jozkee]

One CI error is #70969, the other one is System.Net.Http test failures (couldn't find a related issue).