Home > Posts > Using cross-platform fswatch utility for monitoring file system changes

Using cross-platform fswatch utility for monitoring file system changes

I was just looking for a way to monitor for file system changs in a cross-platform way.

After searching the answers at a related question on StackExchange and the ones at the other question mentioned as possible duplicate in that question’s comments, I think I’d go with fswatch since it is has cross-platform support. Contributed the following answer to collect info I gathered on fswatch.

It uses different kinds of monitors for different OS and can choose the appropriate one automatically, or allow one to specify which one to use and even pass custom platform-specific parameters to the respective monitor.

The list of monitors it currently supports is:

· A monitor based on the File System Events API of Apple OS X.

· A monitor based on kqueue, an event notification interface introduced in FreeBSD 4.1 and supported on most *BSD systems (including OS X).

· A monitor based on inotify, a Linux kernel subsystem that reports file system changes to applications.

· A monitor based on File Events Notification, a Solaris/Illumos kernel API that reports file events.

· A monitor based on ReadDirectoryChangesW, a Microsoft Windows API that reports changes to a directory.

· 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 stat (2) can be used.

It seems to be available via apt-get on Debian/Ubuntu Linuxes. See how to install via apt-get and use fswatch.

FreeBSD and OS-X package-based installation support for fswatch is provided by its author.

Can also build and install it at other OSes, found an article+video showing how to make and install fswatch on CentOS.

There is also an other article that shows the same manual process to build/install (and use) fswatch for Linux.

Windows-based package-based installation support doesn’t seem to be available yet (e.g. no package for Chocolatey yet, and no package for Vcpkg)

There is also extensive documentation for fswatch, though docs for the latest 1.5 version point to 1.4 ones currently. See how to convert commands for fswatch 0.x to fswatch 1.x

Tips for manually choosing a monitor (currently not updated to mention all monitors)

Read about fswatch usage here, here and here and a tutorial intro here

A library named libfswatch is kept in sync with the fswatch tool. See here and a newer doc here. Note that the library is versioned differently from fswatch utility itself. Specifically, the 1.14.0 library doc states:

"libtool’s versioning scheme is described by three integers: current:revision:age.

· current is the most recent interface number implemented by the library.

· revision is the implementation number of the current interface.

· age is the difference between the newest and the oldest interface that the library implements.

Beware that there is also another similar s/w called fswatch (that is go-related I think).

  1. 2020/08/15 at 21:20

    For Solaris do note the comment “The behaviour depends on the monitor. Solaris File Events Notification will tell you that a directory has changed when a file has been created, but won’t give you any more details. It’s up to the receiver to scan the directory contents and see what file has been created.” at https://github.com/emcrisostomo/fswatch/issues/228

  2. 2020/08/15 at 21:23

    Also, note the license is GPL v3.0, so you should avoid statically linking to libfswatch (but dynamically link to its shared library instead) or prefer using the fswatch utility instead if you don’t want to be forced to share the source code of your app too.
    Regarding having to share fswatch’s source code, guess sharing a URL to its source code repository should be enough (that one has the most up to date version of the code anyway).

  1. No trackbacks yet.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.