FileSystemWatcher on sub-directory prevents parent directory from being renamed

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Using a slight variation of this MS Learn example https://learn.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher?view=net-8.0#examples

1. Create a parent directory and a sub-directory.
2. Put a FileSystemWatcher on the sub-directory (as per above example, although they may not all be needed)
3. Try to rename the parent directory (e.g. from File Explorer).

Expected behavior

1. Folder is renamed successfully
2. Perhaps FileSystemWatcher raises an appropriate changed event for the sub-directory. The full path is changed so I assume it should count as a change.

Actual behavior

1. Get this error

Interestingly, the parent directory is incorrectly locked against renaming, but deleting the parent folder succeeds.

Source:

var parentDirectoryInfo = Directory.CreateTempSubdirectory(@"__watchertest");
var subDirectoryInfo = Directory.CreateDirectory(Path.Combine(parentDirectoryInfo.FullName, "foo"));

Console.WriteLine($"Parent directory: {parentDirectoryInfo.FullName}");

var subDirectoryWatcher = new FileSystemWatcher(subDirectoryInfo.FullName);
subDirectoryWatcher.NotifyFilter = NotifyFilters.Attributes
								| NotifyFilters.CreationTime
								| NotifyFilters.DirectoryName
								| NotifyFilters.FileName
								| NotifyFilters.LastAccess
								| NotifyFilters.LastWrite
								| NotifyFilters.Security
								| NotifyFilters.Size;

subDirectoryWatcher.Changed += OnChanged;
subDirectoryWatcher.Created += OnCreated;
subDirectoryWatcher.Deleted += OnDeleted;
subDirectoryWatcher.Renamed += OnRenamed;
subDirectoryWatcher.Error += OnError;

subDirectoryWatcher.IncludeSubdirectories = true;
subDirectoryWatcher.EnableRaisingEvents = true;

Console.WriteLine("Press enter to exit.");
Console.ReadLine();

static void OnChanged(object sender, FileSystemEventArgs e)
{
	if (e.ChangeType != WatcherChangeTypes.Changed)
	{
		return;
	}
	Console.WriteLine($"Changed: {e.FullPath}");
}

static void OnCreated(object sender, FileSystemEventArgs e)
{
	string value = $"Created: {e.FullPath}";
	Console.WriteLine(value);
}

static void OnDeleted(object sender, FileSystemEventArgs e) =>
   Console.WriteLine($"Deleted: {e.FullPath}");

static void OnRenamed(object sender, RenamedEventArgs e)
{
	Console.WriteLine($"Renamed:");
	Console.WriteLine($"    Old: {e.OldFullPath}");
	Console.WriteLine($"    New: {e.FullPath}");
}

static void OnError(object sender, ErrorEventArgs e) =>
   PrintException(e.GetException());

static void PrintException(Exception? ex)
{
	if (ex != null)
	{
		Console.WriteLine($"Message: {ex. Message}");
		Console.WriteLine("Stacktrace:");
		Console.WriteLine(ex. StackTrace);
		Console.WriteLine();
		PrintException(ex. InnerException);
	}
}

As another scenario I added another FileSystemWatcher to the parent directory and if I delete the parent directory from File Explorer, then undo the deletion to restore the parent directory there's some inconsistencies. The parent directory stops getting FSW notifications. But the sub-directory FSW continues to get events. Yet, it is now possible to rename the parent directory.

---

Original Comments

Feedback Bot on 5/23/2024, 09:13 AM:

(private comment, text removed)

anfirszo [MSFT] on 6/2/2024, 10:15 PM:

(private comment, text removed)

Cameron Miller on 6/13/2024, 01:19 AM:

(private comment, text removed)

Feedback Bot on 6/12/2024, 10:44 AM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[dotnet-policy-service]

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

[jozkee]

This is just how Windows works, it blocks directories with open handles. FSW acquires a handle for the watched directory here.

This is non-actionable for us as there's nothing we can do on our side, this is also not exclusive to FileSystemWatcher, as I already mentioned.

A possible workaround is to first move the watched directories and the continue to move the parent ones. Or do a directory copy (that would be easier to achieve once #60903 gets resolved).