Whether the path slot of a file-change contains an absolute path or a path relative to the path given to <monitor> is unspecified, and may even vary on the same platform. User code should not assume either case.

If the immediate path being monitored was changed, then path will equal ""; however this condition is not reported on all platforms. See below.

macOS
Factor uses FSEventStreams to implement monitors on macOS. This requires macOS 10.5 or later.

FSEventStreams always monitor directory hierarchies recursively, and the recursive? parameter to <monitor> has no effect.

The changed slot of the file-change word tuple always contains +modify-file+ and the path slot is always the directory containing the file that changed. Unlike other platforms, fine-grained information is not available.

Only directories may be monitored, not individual files. Changes to the directory itself (permissions, modification time, and so on) are not reported; only changes to children are reported.

Windows
Factor uses ReadDirectoryChanges to implement monitors on Windows.

Both recursive and non-recursive monitors are directly supported by the operating system.

Only directories may be monitored, not individual files. Changes to the directory itself (permissions, modification time, and so on) are not reported; only changes to children are reported.

Linux
Factor uses inotify to implement monitors on Linux. This requires Linux kernel version 2.6.16 or later.

Factor simulates recursive monitors by creating a hierarchy of monitors for every subdirectory, since inotify can only monitor a single directory. This is transparent to user code.

Inside a single with-monitors scope, only one monitor may be created for any given directory.

Both directories and files may be monitored. Unlike macOS and Windows, changes to the immediate directory being monitored (permissions, modification time, and so on) are reported.