Incorrect watcher reporting following directory rename on Linux

[davidmorgan]

@mraleph

Related to #61860 but this time the directory that gets renamed is a parent of the directory being watched.

import 'dart:io';

void main() async {
  final d = Directory.systemTemp.createTempSync();
  final d2 = Directory('${d.path}/2')..createSync();
  final d3 = Directory('${d2.path}/3')..createSync();
  d3.watch().listen(
      (e) => print('for ${d3.path}: $e'),
      onDone: () => print('closed ${d3.path}'));
  File('${d3.path}/f').createSync();
  final newName = '${d2.path}-renamed/3';
  d2.rename('${d2.path}-renamed');
  Directory(newName).watch().listen(
      (e) => print('for $newName: $e'),
      onDone: () => print('closed ${newName}'));

  File('$newName/g').createSync();

  await Future.delayed(Duration(seconds: 1));

  File('$newName/h').createSync();
}

prints

for /tmp/IJKIQC/2/3: FileSystemCreateEvent('/tmp/IJKIQC/2/3/f', isDirectory=false)
for /tmp/IJKIQC/2-renamed/3: FileSystemCreateEvent('/tmp/IJKIQC/2/3/f', isDirectory=false)
for /tmp/IJKIQC/2/3: FileSystemCreateEvent('/tmp/IJKIQC/2/3/g', isDirectory=false)
for /tmp/IJKIQC/2-renamed/3: FileSystemCreateEvent('/tmp/IJKIQC/2/3/g', isDirectory=false)
for /tmp/IJKIQC/2/3: FileSystemCreateEvent('/tmp/IJKIQC/2/3/h', isDirectory=false)
for /tmp/IJKIQC/2-renamed/3: FileSystemCreateEvent('/tmp/IJKIQC/2/3/h', isDirectory=false)

this one seems like an actual bug: what seems to be happening is that the watch on the pre-rename watcher stays open, and the watch on the post-rename path never receives events with the new name, it receives new events much later under the old path.

[davidmorgan]

@mraleph so this one makes sense

• the OS does not notify about the subdirectory move at all
• the VM has the old path and keeps reporting using the old path
• when the new watch is opened the VM finds the old watch and uses the old path

but it's definitely problematic :) not sure what to do here.

[mraleph]

I think we can do something, but how reliable it is going to be is a question: lets say we have been watching path /a/b/c an we are creating a new watch /d/e/f. If we get back the same watch id we can go and check if /a/b/c still exists and has the same inode number (should be accessible via stat). If it does not exist then we (possibly) have some variation of move on our hands. If we have a stream of events we can't reliably figure out which ones belong where (e.g. if the directory moved several times - how do we know which one actually moved it to /d/e/f?). But we can at least fix the path in events stream to use the currently valid one and keep the correct watcher open.

[davidmorgan]

Thanks.

Instead of continuing to push on details like this for package:watcher I'm going to take a step back and see if we can come up with simple+attainable requirements from the point of view of build_runner/analyzer :) so will pause this, and return when I can figure out if something is needed.

[davidmorgan]

A workable workaround :) for package:watcher seems to be to immediately close watches when there is a delete/move event about them

dart-lang/tools#2244

--package:watcher treats the move destination as a new directory and lists+watches it, so it's okay if there is some delay in creating the new watch.

Based on the discussion in this issue that fix should only work if there are no other watches causing the VM to keep the watch open. So I was expecting to still be able to repro the issue with package:watcher by adding some extra watches alongside. But, I did not succeed in creating a repro along those lines.

Since I anyway would like to come up with a different approach for package:watcher mid-long term I will stop digging for now, this seems like a good enough short term workaround.