Run Windows directory watcher in an isolate.

Author: davidmorgan

pkgs/watcher/CHANGELOG.md

@@ -6,6 +6,10 @@
 - `DirectoryWatcher` on Windows performance: reduce 100ms buffering of events
   before reporting to 5ms, the larger buffer isn't needed for correctness after
   the various fixes.
+- `DirectoryWatcher` on Windows watches in a separate Isolate to make buffer
+  exhaustion, "Directory watcher closed unexpectedly", much less likely. The old
+  implementation which does not use a separate Isolate is available as
+  `DirectoryWatcher(path, runInIsolateOnWindows: false)`.
 - Bug fix: while listing directories skip symlinks that lead to a directory
   that has already been listed. This prevents a severe performance regression on
   MacOS and Linux when there are more than a few symlink loops.

pkgs/watcher/lib/src/directory_watcher.dart

@@ -20,6 +20,8 @@ import 'directory_watcher/windows.dart';
 /// the message "Directory watcher closed unexpectedly" on the event stream. The
 /// code using the watcher needs to do additional work to account for the
 /// dropped events, for example by recomputing interesting files from scratch.
+/// By default, the watcher is started in a separate isolate to make this less
+/// likely. Pass `runInIsolateOnWindows = false` to not launch an isolate.
 ///
 /// On Linux, the underlying SDK `Directory.watch` fails if the system limit on
 /// watchers has been reached. If this happens the SDK exception is thrown, it
@@ -40,7 +42,11 @@ abstract class DirectoryWatcher implements Watcher {
   /// shorter will give more immediate feedback at the expense of doing more IO
   /// and higher CPU usage. Defaults to one second. Ignored for non-polling
   /// watchers.
-  factory DirectoryWatcher(String directory, {Duration? pollingDelay}) {
+  ///
+  /// On Windows, pass [runInIsolateOnWindows] `false` to not run the watcher
+  /// in a separate isolate to reduce buffer exhaustion failures.
+  factory DirectoryWatcher(String directory,
+      {Duration? pollingDelay, bool runInIsolateOnWindows = true}) {
     if (FileSystemEntity.isWatchSupported) {
       var customWatcher = createCustomDirectoryWatcher(
         directory,
@@ -49,7 +55,10 @@ abstract class DirectoryWatcher implements Watcher {
       if (customWatcher != null) return customWatcher;
       if (Platform.isLinux) return LinuxDirectoryWatcher(directory);
       if (Platform.isMacOS) return MacOSDirectoryWatcher(directory);
-      if (Platform.isWindows) return WindowsDirectoryWatcher(directory);
+      if (Platform.isWindows) {
+        return WindowsDirectoryWatcher(directory,
+            runInIsolate: runInIsolateOnWindows);
+      }
     }
     return PollingDirectoryWatcher(directory, pollingDelay: pollingDelay);
   }

pkgs/watcher/lib/src/directory_watcher/directory_list.dart

@@ -142,12 +142,17 @@ class _ResolvedDirectory {
     } on FileSystemException catch (e, s) {
       // The first operation on a directory is to resolve symbolic links, which
       // fails with a general FileSystemException if the file is not found.
-      // Convert that into a PathNotFoundException as that makes more sense
-      // to the caller, who didn't ask for anything to do with symbolic links.
-      if (e.message.contains('Cannot resolve symbolic links') &&
-          e.osError?.errorCode == 2) {
-        throw Error.throwWithStackTrace(
-            PathNotFoundException(directory.path, e.osError!), s);
+      // Convert that into a PathNotFoundException or PathAccessException
+      // as that makes more sense to the caller, who didn't ask for anything to
+      // do with symbolic links.
+      if (e.message.contains('Cannot resolve symbolic links')) {
+        if (e.osError?.errorCode == 2) {
+          throw Error.throwWithStackTrace(
+              PathNotFoundException(directory.path, e.osError!), s);
+        } else if (e.osError?.errorCode == 5) {
+          throw Error.throwWithStackTrace(
+              PathAccessException(directory.path, e.osError!), s);
+        }
       }
       rethrow;
     }