Cover V02, I03
Figure 1
Figure 2
Figure 3
Listing 1
Listing 2


fchange: A File System Watchdog

Steven G. Isaacson

Few things are more annoying for a system administrator than spending hours figuring out why something no longer works, only to discover that someone (perhaps another sysadmin, or some user who knows the root password) has changed a critical system file. An unadvertised change to /etc/profile, for example, can precipitate a lot of head scratching.

The problem is communication. If you know that the kernel was recently relinked, or that a uucp configuration file was changed, you can narrow your search for the source of the (new) problem.

Rather than rely on my collegues to keep me well-informed, I use a utility, fchange, that automatically tells me about important file system changes.


fchange is a filesystem watchdog that sends mail whenever a specified file has changed. For example:

This file was changed recently on Dev
----r----- 1 bin mem 604136 Jul 21 1992 /unix

fchange includes a detailed listing from /bin/ls, so you know the last modification time, the owner, size, etc., of the modified file. A file-tracking mode will even make a copy of the file.

fchange consists of a shell script, a files file (containing the files to watch and users to notify), and a control directory. An entry in root's crontab runs fchange every 15 minutes. The fchange shell script employs a simple algorithm:

while there are more lines to read in the files file, read them; if the specified file has changed, send mail.

To determine if a specified file has changed fchange compares the current output from /bin/ls to a previous result. Previous results are maintained in an automatically generated log file. fchange creates a log for each file you want to track. For example, the log file for tracking /unix might be called 01.unix.

The first time fchange looks at /unix, 01.unix is empty, so a new entry is made:

----r------ 1 bin mem 604136 Jul 21 1992 /unix

From then on, fchange works as follows:

  • it counts the number of lines in the log file;

  • runs ls -l to add a new line to the log file;

  • sorts the log file uniquely;

  • counts the number of lines in the log file again;

  • checks to see if there is a new line in the log file after the unique sort has completed; if there is, then the file (and now the log file) has changed; sends mail.

    In Figure 1 the file has not changed. Figure 2 shows the process when the file has changed.

    As an added benefit, fchange keeps a running history of the changes made to your file. You can see at a glance how many times a certain file was changed in the past, say, six months.

    The files File

    The straightforward files file contains three fields per record. The first field is an arbitrary string that uniquely identifies the line. I simply "number" the lines, starting with 01. The second field contains the directory path and filename. The third field contains the mail-to names (or aliases), and the optional keyword track. Blank lines and lines beginning with a pound sign are ignored (see Figure 3).

    The optional tracking feature provides two benefits. First, if the file you are watching gets removed or horribly corrupted, you have a readily accessible backup copy. Second, it makes it easy to quickly determine what was changed because you have the before copy and after copy in the fchange log directory (see fcdiff below).

    Note that the tracking feature also comes with two caveats. First, the files are tracked by cat'ing them to the log file. So if you try to track a binary file, you'll end up with unusable copies of it in the log directory; they will be unusable because new copies are appended to the log file, along with a one line date stamp. The mixture immediately turns to mush.

    The second caveat involves the track file itself. If you are watching a file that changes several times a day, the track file can quickly grow in size. You may need to put it under maxtab control (see Sys Admin, Vol. 2, No. 2, "maxtab: Automatic File Pruning").

    Installing fchange

    fchange requires a control directory. A subdirectory, logs, within the control directory contains the log files and any files that are tracked. For example:


    The control directory also contains the files file, named fchange.files, and the script (see Listing 1).

    On my primary system, I've scheduled fchange to run every fifteen minutes during the day, and once at night. The frequency is determined by the cron entry that runs

    You can run as often or as little as you like. If any of the specified files have changed since the last time it was run, you will get mail.

    fchange Utility

    I use the utility fcdiff, Listing 2, to find differences between the last two copies of a tracked file. fcdiff must to be run in the fchange control directory, because it needs access to the files file.

    Usage: fcdiff [-n log number] \
    [-f filename]

    The log number is the key to your file. If you know the log number, you can specify it on the command-line and immediately view the changes. fcdiff looks in the log directory for the appropriate track file (for example, 14.log.track). The last two entries in the track file are then written out to temp files and diffed. You can then quickly see what changed.

    If you specify the file name, fcdiff will grep the files file for the name. The log number is displayed for any matches.


    I recommend using fchange to watch and track key files on every machine. This is particularly helpful on the occasional `isolated' system in which general access is ostensibly denied. If /etc/passwd changes, you want to know about it.

    In short, fchange is a boon for system administrators. You train the system to watch itself, and it does.

    About the Author

    Steven G. Isaacson has been writing C and Informix 4GL applications since 1985. He is currently developing automated testing tools for FourGen Software, the leading developer of accounting software and CASE Tools for the UNIX market. He may be reached via email at uunet!4gen!steve1 or