Repository navigation
FileSystemWatcher doesn't trigger Deleted event for file when watched directory is deleted on OSX #44484
Description
Description
Create a FileSystemWatcher that watches a directory.
Create a file in that directory and observe Created event.
Delete the file and observe Deleted event.
Create another file in that directory and observe Created event.
Delete the directory, and no deleted event ever arrives.
Configuration
- Which version of .NET is the code running on? .NET 5.0
- What OS and version, and what distro if applicable? OSX 10.13.6
- What is the architecture (x64, x86, ARM, ARM64)? x64
- Do you know whether it is specific to that configuration? It appears to be specific to OSX
Regression?
Not a regression, but different than other platforms
Other information
May be similar to #30415
Discovered when working on #41426
Repro:
using System;
using System.IO;
using System.Threading.Tasks;
namespace fileWatch
{
class Program
{
static async Task Main(string[] args)
{
int waitTime = 1000;
var rootPath = Path.Combine(Path.GetTempPath(), Path.GetRandomFileName());
var subDir = Path.Combine(rootPath, "sub");
Directory.CreateDirectory(rootPath);
Directory.CreateDirectory(subDir);
using (var fsw = new FileSystemWatcher(rootPath, "*"))
{
fsw.Created += (o, e) => Console.WriteLine($"Created {e.FullPath}");
fsw.Deleted += (o, e) => Console.WriteLine($"Deleted {e.FullPath}");
fsw.IncludeSubdirectories = true;
fsw.EnableRaisingEvents = true;
var fileLocation = Path.Combine(subDir, Path.GetRandomFileName());
File.WriteAllText(fileLocation, "temp");
await Task.Delay(waitTime);
File.Delete(fileLocation);
await Task.Delay(waitTime);
fileLocation = Path.Combine(subDir, Path.GetRandomFileName());
File.WriteAllText(fileLocation, "temp");
await Task.Delay(waitTime);
Directory.Delete(subDir, true);
await Task.Delay(waitTime);
fileLocation = Path.Combine(rootPath, Path.GetRandomFileName());
File.WriteAllText(fileLocation, "temp");
await Task.Delay(waitTime);
File.Delete(fileLocation);
await Task.Delay(waitTime);
fileLocation = Path.Combine(rootPath, Path.GetRandomFileName());
File.WriteAllText(fileLocation, "temp");
await Task.Delay(waitTime);
Directory.Delete(rootPath, true);
await Task.Delay(waitTime);
Console.WriteLine(File.Exists(fileLocation));
}
}
}
}
Activity
ericstj commentedon Nov 10, 2020
This appears to be unique to only when the root-level watched directory is removed. If a directory underneath the root directory is removed then the deleted event is observed. I've updated the sample above to better illustrate this.
carlossanlop commentedon Nov 14, 2020
It was my understanding that
FileSystemWatcherdoes not watch changes in the monitored directory itself, only on the files and directories inside it.I remembered that fact from this closed issue, from which I learned that not even Windows reports events from the monitored directory itself. That is how the behavior is described in the Windows API we invoke: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-readdirectorychangesw
jozkee commentedon Nov 14, 2020
@ericstj the sample you provided behaves similar to what you describe on Windows and Linux, is there something that I am missing?
This is the output that I get:
ericstj commentedon Nov 14, 2020
This failure is specific to Mac (OSX) which uses a different implementation. On Mac the last deleted event will be missing.
jozkee commentedon Nov 16, 2020
I see now, it is reporting Create twice and not reporting Delete when you erase the root as you mentioned:
dotnet-policy-service commentedon May 18, 2025
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.
This process is part of our issue cleanup automation.
dotnet-policy-service commentedon Jun 2, 2025
This issue will now be closed since it had been marked
no-recent-activitybut received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.