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. Mac OS X
Factor uses FSEventStream
s to implement monitors on Mac OS X. This requires Mac OS X 10.5 or later. FSEventStream
s always monitor directory hierarchies recursively, and the recursive?
parameter to <monitor>
has no effect.
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 Mac OS X and Windows, changes to the immediate directory being monitored (permissions, modification time, and so on) are reported.