File system watching does not detect changes on /System/Volumes/Data/... on macOs

[jdochez]

This is a follow up to
https://buganizer.corp.google.com/issues/196982364

The file watching service is not sending file changes any longer and Gradle will think all tasks are up to date.
Please see referenced bugs for context.

as of time of filing :

• turning off file watcher solves the issue for the user.
• not a timing issue, the file watcher service is just not working any longer.
• not enough data to know if this is OS X issue only.

[PhilippNowak96]

@jdochez thanks for posting it here.

For the Gradle team: I experienced this issue. If you need any information, feel free to ping me here.

[wolfs]

This may be related to fseventsd not working properly. When this happens next time, please take a look at the CPU usage of this process. It would be also great if you could sign up on the Gradle community slack, so we could have a more real-time connection when the problem re-occurs.

[wolfs]

We seem to have found the problem, together with @PhilippNowak96:

The problem is only for macOS. It seems like newer macOS versions introduce a data volume, which is in /System/Volumes/Data. The contents of this volume are visible in the file system root. So for example, /System/Volumes/Data/Users is in /Users.

Now, when somebody creates a custom directory in /System/Volumes/Data, then this is not mapped to the file system root /. Though it seems that file system events are reported relative to that directory, as shown in this build scan.

The solution is to move the project directory to the /Users directory and run the build from there. We still need to find out why we report the wrong path for the directory.

[lptr]

This issue has caused us to re-evaluate the way we enable file system watching by default. Clearly, there are cases where we can't rely on events being delivered, and playing whack-a-mole with corner cases like this doesn't help anyone. So: new approach!

When we enable file system watching for a hierarchy (=build root, basically), we'll also make a change to the file system under that root. Unless we hear back about that change by the start of the next build, we'll discard the corresponding part of the VFS.

In other words, we will only rely on information about a hierarchy in the VFS from a previous build if we can prove that we got at least one event from the file system about that hierarchy.