PhysicalFileProvider.UsePollingFileWatcher returns false after polling watcher initialization
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- csharp
- Domain
- operating-systems
Research direction
Start at the PhysicalFileProvider.UsePollingFileWatcher getter and the _fileWatcher initialization described in the issue. Reproduce the behavior with Watch("appsettings.json"), then verify that the getter reports the initialized watcher's PollForChanges value while the existing post-initialization setter behavior remains unchanged.
Written by the indexing model from the issue text.
Description
Description
PhysicalFileProvider.UsePollingFileWatcher reports false after the file watcher has been initialized, even when the initialized watcher is using polling.
The getter currently contains:
if (_fileWatcher != null)
{
return false;
}
This conflicts with the property's documentation (and its name), which says it determines whether the provider "uses polling to determine file changes."
Reproduction
using var provider = new PhysicalFileProvider(root)
{
UsePollingFileWatcher = true,
};
_ = provider.Watch("appsettings.json"); // Initializes the watcher.
Console.WriteLine(provider.UsePollingFileWatcher); // False
The same misleading result occurs on platforms where PhysicalFileProvider automatically falls back to polling.
Expected behavior
UsePollingFileWatcher should continue to report whether the initialized provider uses polling. Once _fileWatcher is initialized, its internal PollForChanges property contains the effective value, so the getter could return it:
if (_fileWatcher is not null)
{
return _fileWatcher.PollForChanges;
}
This would not change the setter's existing behavior: attempting to modify the setting after initialization would still throw.
History
The getter originally threw after initialization. #36397 reported that property getters should not throw, and dotnet/extensions#2099 changed the getter to return false. Reviewers explicitly retained that behavior, but the discussion did not address the resulting inaccurate value when polling was enabled.
[!NOTE]
This issue was drafted with GitHub Copilot.
- Dominant language
- C#
- Stars
- 18.3k
- Forks
- 5.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 633
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/runtime
-
agentic-workflows area-Infrastructure untriaged
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
agentic-workflows area-Infrastructure untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
area-System.Reflection blocking-clean-ci-optional Known Build Error os-mac-os-x untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
area-CodeGen-coreclr untriaged
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
agentic-workflows area-Infrastructure untriaged
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Similar issues
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
t/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
ci-failure-cause test-failure
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area:auth FE mvp P3
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
klasolsson81/jobbliggaren#1788 ·