Windows directory watcher flaky reporting of link type for new link to directory

[davidmorgan]

@mraleph another fun one around file watching, any chance you could take a quick look please?

Repro:

import 'dart:async';
import 'dart:io';

void main() async {
  final workspace = Directory.systemTemp.createTempSync();
  final sep = Platform.pathSeparator;
  final targetDir = '${workspace.path}${sep}targets/targetdir';
  Directory(targetDir).createSync(recursive: true);
  final linksDir = '${workspace.path}${sep}links';
  Directory(linksDir).createSync();
  Directory(linksDir).watch().listen((e) {
    print('${e.isDirectory ? 'd' : 'f'} ${e.path}');
  });

  String link(int i) => '${workspace.path}${sep}links${sep}link$i';

  for (var i = 0; i != 25; ++i) {
    await Future<void>.delayed(const Duration(milliseconds: 10));
    unawaited(Link(link(i)).create(targetDir));
  }

  await Future<void>.delayed(const Duration(seconds: 1));
  exit(0);
}

It watches a directory, then creates 25 symlinks to directories in that directory.

The watcher prints each create was reported as a file f or directory d.

On Linux and MacOS all the events are reported as file creates:

f /tmp/QRXSOS/links/link0
f /tmp/QRXSOS/links/link1
f /tmp/QRXSOS/links/link2
f /tmp/QRXSOS/links/link3
f /tmp/QRXSOS/links/link4
...

But on Windows the type randomly flips between the two:

f C:\Users\davidmorgan\AppData\Local\Temp\eb7096fb\links\link0
f C:\Users\davidmorgan\AppData\Local\Temp\eb7096fb\links\link1
d C:\Users\davidmorgan\AppData\Local\Temp\eb7096fb\links\link2
d C:\Users\davidmorgan\AppData\Local\Temp\eb7096fb\links\link3
f C:\Users\davidmorgan\AppData\Local\Temp\eb7096fb\links\link4
d C:\Users\davidmorgan\AppData\Local\Temp\eb7096fb\links\link5
...

So it looks like there is some race between what the OS is doing and what the Dart VM is doing that causes it be reported one way or the other.

Using createSync when creating the links seems to exactly avoid the race, i.e. the Dart VM is busy creating the link so it can't observe the half-created link.

// not this: unawaited(Link(link(i)).create(targetDir));
// but this instead.
Link(link(i)).createSync(targetDir)

but while that "helps" in tests it doesn't help for real cases :) where the link is created by someone else and there can be a race.

If I make the watcher do a FileSystemEntity.typeSync check when the event says it's a new directory

    if (isDirectory &&
        FileSystemEntity.typeSync(e.path, followLinks: false) !=
            FileSystemEntityType.directory) {
      isDirectory = false;
    }

then that helps but not 100%, so "typeSync" apparently also returns type directory for some small period of time during link creation.

So I guess the question is, is there anything the VM can do to make this consistent; if not, what's the workaround, and I guess another caveat in the docs is needed to explain this rather awkward case :)

Thanks :)

[mraleph]

On Linux and Mac OS X file watcher receives type of affected file system entity as part of the event. On Windows we just get a path - so isDirectory bit you are getting with the event is computed using the path and typeSync. This explains why you see the same behavior from e.isDirectory and typeSync.

Now there is an interesting question why the type flip-flops. I think that because of how symbolic links are implemented on Windows: I think the operation CreateSymbolicLinkW is not atomic. It creates a file system entity first and then it associates a reparse point with it. So you can observe it in different states.

Note that in general you can't really rely on any bits in these file system events for anything significant: changes to file system naturally racing with processing of filesystem events. What was a directory at some point might not be a directory anymore by the time you are trying to do something with it. So you have code defensively and accept high likely-hood of races.

[davidmorgan]

Ah, yes, I see what's happening now, thanks.

The file system entity for a link to a directory is created as a directory, then after that FILE_ATTRIBUTE_REPARSE_POINT is set.

In runtime/bin/file_win.cc File::GetType we can see that this changes the type from kIsDirectory to kIsLink. FileSystemEvent does not distinguish links from files, it's just reported as isDirectory = false.

Will see if I can figure out a way to make this appear consistent across platforms for package:watcher, or whether that can only be done after a breaking change for how symlinks are reported.

[davidmorgan]

I think it ends up being a straightforward workaround in package:watcher, it already waits 100ms before processing events on Windows so it can just recheck the type. dart-lang/tools#2223

[davidmorgan]

I can't think of any good VM change for this, so I guess just mention in the docs

https://dart-review.googlesource.com/c/sdk/+/457320

[davidmorgan]

Closing as I don't think there's anything more to be done. Thanks Slava :)