.\" $Id$ .\" Copyright (c) 2013-2026 Enrico M. Crisostomo .\" .\" This program is free software; you can redistribute it and/or modify .\" it under the terms of the GNU General Public License as published by .\" the Free Software Foundation; either version 3, or (at your option) .\" any later version. .\" .\" This program is distributed in the hope that it will be useful, .\" but WITHOUT ANY WARRANTY; without even the implied warranty of .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the .\" GNU General Public License for more details. .\" .\" You should have received a copy of the GNU General Public License .\" along with this program. If not, see . .\" .\" Man page for the fswatch command. .\" .\" $Log$ .\" .Dd August 05, 2026 .Dt "fswatch" "7" "fswatch file system monitor" .Os "pc" "linux-gnu" .Pp .Sh NAME .Nm fswatch .Nd Ask for notification when the contents of the specified files or directory hierarchies are modified. .Pp This man page is kept for reference but it is not to be considered an authoritative or complete source of information. Please, consult the official Info documentation shipped with .Nm . .Sh SYNOPSIS .Nm fswatch (option)* path+ .Sh DESCRIPTION The .Nm command receives notifications when the contents of the specified files or directories are modified. fswatch implements seven kind of monitors: .Bl -tag -width indent .It - A monitor based on the File System Events API of Apple macOS. .It - A monitor based on kqueue, an event notification interface introduces in FreeBSD 4.1 and supported on most *BSD systems (including macOS). .It - A monitor based on the File Events Notification API of the Solaris kernel and its derivatives. .It - A monitor based on inotify, a Linux kernel subsystem that reports file system changes to applications. .It - A monitor based on fanotify, a Linux kernel subsystem that can report file system changes with optional process attribution. .It - A monitor based on the ReadDirectoryChangesW Microsoft Windows API. Native MinGW-w64 builds are the recommended Windows target; Cygwin builds are kept for compatibility when the Cygwin path conversion API is available. .It - A monitor which periodically stats the file system, saves file modification times in memory and manually calculates changes. .El .Pp .Nm writes a record for each event it receives containing: .Bl -tag -width indent .It - The timestamp when the event was .Em received (optionally). .It - The path affected by the current event. .It - A space-separated list of .Em event types (see .Sx EVENT TYPES ). .El .Pp By default, .Nm enters an infinite loop and never returns. When it receives a SIGABRT, SIGINT or SIGTERM signal, .Nm closes the notification streams and exits gracefully returning 0 to the calling process. (Unless running in .Op Fl 1, -one-event mode, in which case it sets its return code according to the signal it received, as usual.) .Pp The following options are available: .Bl -tag -width indent .It Fl 0, -print0 Use the ASCII NUL character (\e0) as line separator. Since file names can potentially contain any character but NUL, this option assures that the output of fswatch can be safely parsed using NUL as delimiter, such as using xargs -0 and the shell builtin read -d ''. .It Fl 1, -one-event Exit fswatch after the first set of events is received. .It Fl -batch-marker Ar marker Print a marker at the end of every batch. An optional marker .Ar marker can be specified to override its default value `NoOp'. .It Fl -event Ar name Filter event with the specified .Ar name . This option can be used multiple times, one for each event .Ar name that must be included in the output. .It Fl e, -exclude Ar regexp Exclude paths matching .Ar regexp . Multiple exclude filters can be specified using this option multiple times. See .Sx FILTERING PATHS for further information. .It Fl E, -extended Use extended regular expressions. .It Fl -filter-mode Ar mode Set the path filter evaluation mode. .Ar mode can be .Ql legacy or .Ql conjunctive . See .Sx FILTERING PATHS for further information. .It Fl f, -format-time Ar format Print the event time using the specified .Ar format . Supported formats are specified by .Xr strftime 3 . .It Fl -format Ar format Use the specified event record format. The .Ar format string supports path, flag, timestamp, correlation, and monitor-specific metadata directives including fanotify process attribution. .It Fl h, -help Show the help message. .It Fl i, -include Ar regexp Include paths matching .Ar regexp . Multiple include filters can be specified using this option multiple times. See .Sx FILTERING PATHS for further information. .It Fl I, -insensitive Use case insensitive regular expressions. .It Fl l, -latency Ar latency Set the .Ar latency in seconds. The latency is a double value greater than 0.1. Smaller values are currently not allowed in order not to compromise the performance of the system. The default latency is 1 second. .It Fl L, -follow-links Follow symbolic links. .It Fl M, -list-monitors List the available monitors. .It Fl m, -monitor Ar name Uses the monitor specified by .Ar name . The list of currently available monitors can be obtained using the .Fl h option. .It Fl -no-defer Sets the kFSEventStreamCreateFlagNoDefer flag on macOS FSEvents monitor, which makes the monitor more responsive. This flag is more appropriate for sessions, while the default behaviour is more appropriate for background, daemon or batch processing apps. .It Fl n, -numeric Print the numeric value of the event flag, instead of the array of symbolic names. The numeric value of the event flags are system-specific and may vary across different versions of macOS. As a consequence, the use of numeric values is discouraged. .It Fl o, -one-per-batch Print a single message with the number of change events. .It Fl -prune Ar regexp Do not descend into directories matching .Ar regexp during recursive traversal. This option may be specified multiple times. See .Sx FILTERING PATHS for further information. .It Fl r, -recursive Watch subdirectories recursively. This option may not be supported on all systems. .It Fl t, -timestamp Print the event timestamp. .It Fl u, -utc-time Print the event time in UTC format. When this option is not specified, the time is printed using the system .Em local time, as defined by .Sy localtime (3) . .It Fl v, -verbose Print verbose output. .It Fl -version Print the version of .Nm and exits. .It Fl x, -event-flags Prints the event flags. .It Fl -event-flag-separator Ar separator Print event flags using the specified .Ar separator . .El .Sh MONITORS .Nm acts as a front-end to system-specific monitors. Currently, the available monitors are: .Bl -tag -width indent .It - The .Em FSEvents monitor , a monitor based on the File System Events API of Apple macOS. .It - The .Em kqueue monitor , a monitor based on kqueue, an event notification interface introduced in FreeBSD 4.1 and supported on most *BSD systems (including macOS). .It - The .Em inotify monitor , a Linux kernel subsystem that reports file system changes to applications. .It - The .Em fanotify monitor , a Linux kernel subsystem that can report file system changes with optional process attribution. .It - The .Em poll monitor , a monitor which periodically stats the file system, saves file modification times in memory and manually calculates file system changes, which can work on any operating system where .Xr stat 2 can be used. .El .Pp Each monitor has its own strengths, weakness and peculiarities. Although .Nm strives to provide a uniform experience no matter which monitor is used, it is still important for users to know which monitor they are using and to be aware of existing bugs, limitations, corner cases or pathological behaviour. .Ss The FSEvents Monitor The .Em FSEvents monitor , available only on Apple macOS, has no known limitations and scales very well with the number of files being observed. In fact, I observed no performance degradation when testing .Nm observing changes on a filesystem of 500 GB over long periods of time. On macOS, this is the default monitor. .Ss The kqueue Monitor The .Em kqueue monitor , available on any *BSD system featuring kqueue, requires a file descriptor to be opened for every file being watched. As a result, this monitor scales badly with the number of files being observed and may begin to misbehave as soon as the .Nm process runs out of file descriptors. In this case, .Nm dumps one error on standard error for every file that cannot be opened. Beware that on some systems the maximum number of file descriptors that can be opened by a process is set to a very low value (values as low as 256 are not uncommon), even if the operating system may allow a much larger value. .Pp If you are running out of file descriptors when using this monitor and you cannot reduce the number of observed items, either: .Bl -tag -width indent .It - Consider raising the number of maximum open file descriptors (check your OS documentation). .It - Consider using another monitor. .El .Ss The inotify Monitor The .Em inotify monitor , available on Linux since kernel 2.6.13, may suffer a queue overflow if events are generated faster than they are read from the queue. In any case, the application is guaranteed to receive an overflow notification which can be handled to gracefully recover. .Nm currently throws an exception if a queue overflow occurs. Future versions will handle the overflow by emitting proper notifications. However, the odds of observing a queue overflow on a default configured mainstream GNU/Linux distribution is very low. .Pp The inotify API provides no information about the user or process that triggered an event, so applications cannot easily distinguish events they trigger themselves from events triggered by other processes. Inotify reports only events triggered through the filesystem API, so it does not catch remote events that occur on network filesystems. Furthermore, pseudo-filesystems such as \fI/proc\fR, \fI/sys\fR, and \fI/dev/pts\fR are not monitorable with inotify. .Pp The inotify API does not report file accesses or modifications that may occur because of \fBmmap(2)\fR, \fBmsync(2)\fR, and \fBmunmap(2)\fR. It identifies affected files by filename, but by the time the application processes the event, the filename may already have been deleted or renamed. Events are identified via watch descriptors, so applications must cache a mapping, if one is needed, between watch descriptors and pathnames. Be aware that directory renamings may affect multiple cached pathnames. .Pp The inotify API sends events for the direct child elements of a watched directory and it scales pretty well with the number of watched items. For this reason, depending on the number of files to watch, it may sometimes be preferable to watch a common parent directory and filter received events rather than adding a huge number of file watches. Inotify monitoring of directories is not recursive, so additional watches must be created for subdirectories. That can take a significant amount of time for large directory trees. .Pp If monitoring an entire directory subtree, and a new subdirectory is created in that tree or an existing directory is renamed into that tree, be aware that by the time you create a watch for the new subdirectory, new files and subdirectories may already exist inside the subdirectory. Therefore, you may want to scan the contents of the subdirectory immediately after adding the watch, and, if desired, recursively add watches for any subdirectories that it contains. .Pp The event queue can overflow. In this case, events are lost. Robust applications should handle the possibility of lost events gracefully. For example, it may be necessary to rebuild part or all of the application cache. .Pp If a filesystem is mounted on top of a monitored directory, no event is generated, and no events are generated for objects immediately under the new mount point. If the filesystem is subsequently unmounted, events will subsequently be generated for the directory and the objects it contains. .Ss The fanotify Monitor The .Em fanotify monitor , available on Linux when the build system detects the required fanotify headers and symbols, uses file-handle based fanotify events. It is not the default Linux monitor; select it explicitly with: .Pp .Dl "$ fswatch -m fanotify_monitor path ..." .Pp The fanotify monitor is useful when Linux-specific process attribution is required. Custom format directive .Em %K prints the identifier kind, such as `pid' or `tid', and .Em %P prints the reported process or thread identifier. The monitor property .Em fanotify.process-id accepts `pid' or `tid'. The .Em fanotify.report-pidfd property requests pidfd reporting when supported by the build headers and kernel; the pidfd is exposed through the library event metadata only while the callback is executing. .Pp Fanotify reports only events triggered through the filesystem API, so it does not catch remote events that occur on network filesystems. It also does not report accesses or modifications that may occur because of \fBmmap(2)\fR, \fBmsync(2)\fR, and \fBmunmap(2)\fR. Directory events are created only if the directory itself is opened, read, and closed, so adding, removing, or changing children of a marked directory does not create events for the monitored directory itself. Fanotify monitoring of directories is not recursive: monitoring subdirectories requires additional marks, and using \fBFAN_CREATE\fR to detect them is racy because events may be lost before a new mark is added. Monitoring mounts or entire filesystems avoids that race. The event queue can also overflow, in which case events are lost. .Pp The .Em fanotify.unlimited-queue and .Em fanotify.unlimited-marks properties request .Em FAN_UNLIMITED_QUEUE and .Em FAN_UNLIMITED_MARKS , respectively. These properties are opt-in because they require matching build headers and the capability expected by the running kernel, typically .Em CAP_SYS_ADMIN , and fanotify initialization fails if the process lacks it. .Pp Fanotify support depends on kernel, C library, filesystem, and permission support for the requested mode. Some filesystems do not support file handles, and some fanotify modes require additional privileges. Use the inotify monitor when broad Linux compatibility is more important than process attribution. .Pp Fanotify directory marks are not equivalent to macOS FSEvents recursive tree watches. With ordinary directory marks, .Em FAN_EVENT_ON_CHILD reports events for immediate children only, not grandchildren or deeper descendants. Recursive fanotify monitoring therefore still marks subdirectories explicitly. Avoiding recursive mark expansion requires fanotify mount or filesystem marks, which have broader scope and different permission constraints. .Ss The Poll Monitor The .Em poll monitor was added as a fallback mechanisms in the cases where no other monitor could be used, including: .Bl -tag -width indent .It - Operating system without any sort of file events API. .It - Situations where the limitations of the available monitors cannot be overcome (i.e.: observing a number of files greater than the available file descriptors on a system using the kqueue monitor). .El .Pp The poll monitor, available on any platform, only relies on available CPU and memory to perform its task (besides the .Xr stat 2 function). The performance of this monitor degrades linearly with the number of files being watched. The authors' experience indicates that .Nm requires approximately 150 MB or RAM memory to observe a hierarchy of 500.000 files with a minimum path length of 32 characters. A common bottleneck of the poll monitor is disk access, since stat()-ing a great number of files may take a huge amount of time. In this case, the latency should be set to a sufficiently large value in order to reduce the performance degradation that may result from frequent disk access. .Ss How to Choose a Monitor .Nm already chooses the "best" monitor for your platform if you do not specify any. However, a specific monitor may be better suited to specific use cases. Please, read the .Sx MONITORS section to get a description of all the available monitors and their limitations. .Pp Usage recommendations are as follows: .Bl -tag -width indent .It - On macOS, use only the FSEvents monitor (which is the default behaviour). .It - On Linux, use the inotify monitor (which is the default behaviour). .It - On Linux, use the fanotify monitor only when its Linux-specific process attribution or fanotify semantics are required. .It - If the number of files to observe is sufficiently small, use the kqueue monitor. Beware that on some systems the maximum number of file descriptors that can be opened by a process is set to a very low value (values as low as 256 are not uncommon), even if the operating system may allow a much larger value. In this case, check your OS documentation to raise this limit on either a per process or a system-wide basis. .It - If feasible, watch directories instead of watching files. Properly crafting the receiving side of the events to deal with directories may sensibly reduce the monitor resource consumption. .It - If none of the above applies, use the poll monitor. The authors' experience indicates that fswatch requires approximately 150 MB or RAM memory to observe a hierarchy of 500.000 files with a minimum path length of 32 characters. A common bottleneck of the poll monitor is disk access, since stat()-ing a great number of files may take a huge amount of time. In this case, the latency should be set to a sufficiently large value in order to reduce the performance degradation that may result from frequent disk access. .El .Sh FILTERING PATHS Received events can be filtered by path using regular expressions. Regular expressions can be used to include or exclude matching paths. .Pp Explicit command-line root paths remain eligible for monitor setup even when an output filter would reject the root path itself. .Nm supports two path filter evaluation modes: .Ql legacy and .Ql conjunctive . .Pp The default .Ql legacy mode preserves historical behavior. The user can specify multiple filter expressions in any order and filters are processed this way: .Bl -tag -width indent .It - If a path matches an including filter, the path is accepted no matter any other filter. .It - If a path matches an excluding filter, the path is rejected. .It - If a path matches no filters, the path is accepted. .El Said another way: .Bl -tag -width indent .It - All paths are accepted .Em by default , unless an exclusion filter says otherwise. .It - Inclusion filters may override any other exclusion filter. .It - The order in the definition of filters in the command line has no effect. .El .Pp The .Ql conjunctive mode is enabled with .Fl -filter-mode=conjunctive . It treats inclusion filters as the candidate set and exclusion filters as subtractions from that set: .Bl -tag -width indent .It - If no inclusion filters are specified, all paths are candidates. .It - If at least one inclusion filter is specified, a path must match an inclusion filter to be a candidate. .It - Any matching exclusion filter rejects the path. .El .Pp Said another way, conjunctive mode accepts paths matching this expression: .Pp .Dl (no includes OR matches include) AND NOT matches exclude .Pp For example, the following command reports changes to C source files except editor lock files: .Pp .Dl $ fswatch --filter-mode=conjunctive -i '\e.c$' -e '/lock-[^/]+\.c$' . .Ss Pruning Recursive Traversal The .Fl -prune Ar regexp option defines regular expressions that stop recursive traversal from descending into matching directories. This is different from .Fl -exclude : excluded paths are filtered from reported events, while pruned directories and their descendants are skipped during library-side recursive traversal. .Pp Pruning only affects monitors that perform this traversal in .Nm . Native recursive backends may accept .Fl -prune , but may not be able to prevent the operating system from traversing matching subtrees in the same way. .Pp Prune expressions use the same case-sensitivity and extended-regular-expression settings as normal path filters. .Pp Pruning is applied only to non-root directories. A command-line root path remains eligible for monitoring even if it matches a prune expression. .Pp For example, the following command recursively watches .Pa /home/me without descending into hidden directories: .Pp .Dl $ fswatch -r --prune '/\e.[^/]+$' /home/me .Pp Other options govern how regular expressions are interpreted: .Bl -tag -width indent .It - Regular expressions can be .Em extended if option .Fl E is specified. .It - Regular expressions can be .Em case insensitive if option .Fl I is specified. .El .Sh EVENT TYPES Event flags identify the kind of change a file system object has undergone. Many of them directly map to common file system operations (such as creation, deletion, update, etc.), others are less common (such as attribute modification), and others are monitor and platform specific. .sp Currently, .Nm maps monitor-specific event flags to 'global' event flags acting as a sort of 'greatest common denominator' of all the available monitor flags. The following global event flags are available:: .Bl -tag -width 20n .It Sy NoOp Idle event, optionally issued when no changes were detected. .It Sy PlatformSpecific This event maps a platform-specific event that has no corresponding flag. .It Sy Created The object has been created. .It Sy Updated The object has been updated. The kind of update is monitor-dependent. .It Sy Removed The object has been removed. .It Sy Renamed The object has been renamed. .It Sy OwnerModified The object’s owner has changed. .It Sy AttributeModified An object’s attribute has changed. .It Sy MovedFrom The object has moved from this location to a new location of the same file system. .It Sy MovedTo The object has moved from another location in the same file system into this location. .It Sy IsFile The object is a regular file. .It Sy IsDir The object is a directory. .It Sy IsSymLink The object is a symbolic link. .It Sy Link The object link count has changed. .It Sy Overflow The monitor has overflowed. .El .Sh EXAMPLES .Ss Basic Usage .Nm syntax is the following: .Pp .Dl $ fswatch [options] [paths] ... .Pp .Nm will then output change events to standard output. By default, only the affected file name is printed. However, many options are available to format the event record, including: .Bl -tag -width indent .It - The possibility of adding the event timestamp. .It - The possibility of adding the event mask in both textual and numerical form. .El .Pp The following command listens for changes in the current directory and events are delivered every 5 seconds: .Pp .Dl "$ fswatch -l 5 ." .Pp The following command listens for changes in the current user home directory and .Em /var/log : .Pp .Dl "$ fswatch ~ /var/log" .Ss Piping fswatch Output to Another Process Very often you wish to not only receive an event, but react to it. The simplest way to do it is piping fswatch output to another process. Since in Unix and Unix-like file system file names may potentially contain any character but .Em NUL (\e0) and the path separator .Em (/) , .Nm has a specific mode of operation when its output must be piped to another process. When the .Op Fl 0 option is used, .Nm will use the .Em NUL character as record separator, thus allowing any other character to appear in a path. This is important because many commands and shell builtins (such as .Em read ) split words and lines by default using the characters in .Em $IFS , which by default contains characters which may be present (although rarely) in a file name, resulting in a wrong event path being received and processed. .Pp Probably the simplest way to pipe .Nm to another program in order to respond to an event is using .Em xargs : .Pp .Dl "$ fswatch -0 [opts] [paths] | xargs -0 -n 1 -I {} [command]" .Pp In this example: .Bl -tag -width indent .It - .Em fswatch -0 will split records using the .Em NUL character. .It - .Em xargs -0 will split records using the .Em NUL character. This is required to correctly match impedance with .Nm . .It - .Em xargs -n 1 will invoke .Em command every record. If you want to do it every .Em x records, then use .Em xargs -n x . .It - .Em xargs -I {} will substitute occurrences of .Em {} in command with the parsed argument. If the command you are running does not need the event path name, just delete this option. If you prefer using another replacement string, substitute .Em {} with yours. .El .Pp On BSD-derived systems, including macOS, the system .Em xargs implementation may limit the size of replacement strings used by .Fl I . If commands fail when processing long path names, consider using a different consumer that reads .Nm Ns 's NUL-separated records directly, or install GNU findutils and use .Em gxargs instead of .Em xargs . .Ss Bubbling Events An often requested feature is being able to receive a single event "per batch", instead of receiving multiple events. This use case is implemented by the .Op Fl o, -one-per-batch option which tells .Nm to dump a record containing the number of received events, without any other detail: .Pp .Dl $ fswatch -or /path/to/watch .Dl 1 .Dl 10 .Dl [...] .Pp This is useful if, for example, you want to respond to change events in a way which is (or can easily be) path-independent (because you are not receiving any event detail) and you prefer to "bubble" events together to reduce the overhead of the command being executed. A typical case is a directory synchronisation job whenever some files change. .Ss Receiving a Single Event Another requested feature is the possibility of receiving a single event and exit. This is most useful when existing scripts processing events include the restart logic of .Nm This use case is implemented by the .Op Fl 1, -one-event option: .Pp .Dl $ fswatch -1 /path/to/watch .Dl /path/to/watch .Sh Compatibility With fswatch 0.x The previous major version of .Nm (v. 0.x) allowed users to run a command whenever a set of changes was detected with the following syntax: .Pp .Dl $ fswatch path program .Pp Starting with .Nm v. 1.x this behaviour is no longer supported. The rationale behind this decision includes: .Bl -tag -width indent .It - The old version only allows watching one path. .It - The command to execute was passed as last argument, alongside the path to watch, making it difficult to extend the program functionality to add multiple path support .It - The old version forks and executes /bin/bash, which is neither portable, nor guaranteed to succeed, nor desirable by users of other shells. .It - No information about the change events is passed to the forked process. .El .Pp To solve the aforementioned issues and keep .Nm consistent with common UNIX practices, the behaviour has changed and .Nm now prints event records to the standard output that users can process further by piping the output of .Nm to other programs. .Pp To fully support the old use, the .Op Fl o, -one-per-batch option was added in v. 1.3.3. When specified, .Nm will only dump 1 event to standard output which can be used to trigger another program: .Pp .Dl $ fswatch -o path | xargs -n1 program .Pp In this case, program will receive the number of change events as first argument. If no argument should be passed to program, then the following command could be used: .Pp .Dl $ fswatch -o path | xargs -n1 -I{} program .Sh EXIT STATUS .Nm may exit with one of the following exit statuses: .Pp .Dl FSW_OK 0 .Dl FSW_ERR_UNKNOWN_ERROR (1 << 0) .Dl FSW_ERR_SESSION_UNKNOWN (1 << 1) .Dl FSW_ERR_MONITOR_ALREADY_EXISTS (1 << 2) .Dl FSW_ERR_MEMORY (1 << 3) .Dl FSW_ERR_UNKNOWN_MONITOR_TYPE (1 << 4) .Dl FSW_ERR_CALLBACK_NOT_SET (1 << 5) .Dl FSW_ERR_PATHS_NOT_SET (1 << 6) .Dl FSW_ERR_UNKNOWN_MONITOR (1 << 7) .Dl FSW_ERR_MISSING_CONTEXT (1 << 8) .Dl FSW_ERR_INVALID_PATH (1 << 9) .Dl FSW_ERR_INVALID_CALLBACK (1 << 10) .Dl FSW_ERR_INVALID_LATENCY (1 << 11) .Dl FSW_ERR_INVALID_REGEX (1 << 12) .Dl FSW_ERR_MONITOR_ALREADY_RUNNING (1 << 13) .Dl FSW_ERR_STALE_MONITOR_THREAD (1 << 14) .Dl FSW_ERR_THREAD_FAULT (1 << 15) .Dl FSW_ERR_UNSUPPORTED_OPERATION (1 << 16) .Dl FSW_ERR_UNKNOWN_VALUE (1 << 17) .Sh DIAGNOSTICS .Nm exits 0 on success, and >0 if an error occurs. .Sh COMPATIBILITY .Nm can be built on any system supporting at least one of the available monitors. .Sh BUGS See https://github.com/emcrisostomo/fswatch/issues for open issues or to create a new one. .Pp Bugs can also be submitted to enrico.m.crisostomo@gmail.com.