If you got here because you searched for [linux file change notification] or
a similar query, you are probably looking for inotify and may
find the following links helpful:
This page is about fschange, an alternative to inotify that I
implemented before inotify became part of the mainline Linux kernel.
fschange – Linux File System Change Notification
dnotify and inotify are the current file change notification
services in the Linux kernel. Unfortunately, they share a couple of shortcomings
that make it difficult to use them for efficient (real-time) file system indexing
under Linux. One of
them is their unability to detect content-preserving file changes, i.e. write
operations that only affect a tiny portion of a file. It is impossible to use inotify
in order to determine what part of a file has actually been modified. A second problem
is that you have to open every directory once before you can register for changes
within that directory. This is very unconvenient, especially if you want to watch
large file systems, as it requires a full scan of the file system.
fschange can be used to keep track of file changes by reading data from
a proc file (/proc/fschange). When data is written to a file, fschange
reports the exact interval that has been modified instead of just saying: "This file
has been changed." It also offers partial support for file changes caused by
mmap and tells you when a file system is mounted or unmounted. The latter
is very useful for per-file-system indexing. fschange informs about changes
to every part of the file system tree. It is not necessary to register for notification
on a per-directory basis. Currently, only root may access this information.
The event types supported by fschange are:
MOUNT device mountpoint (when a new file system is mounted)
UMOUNT mountpoint (when a file system is unmounted)
UMOUNT_REQ mountpoint (when umount has been called but failed due to file system activity, i.e. open files etc.)
WRITE filename from to (after a file has been changed and closed; the latter is important because it helps us reduce the number of events generated)
TRUNCATE filename newfilesize (after a successful call to truncate)
RENAME oldpath newpath (after a file or directory has been renamed or moved)
UNLINK filename (when a file has been removed)
CHMOD filename newfilemode
CHOWN filename newuser newgroup
CREATE filename (after a new file has been created)
MKDIR dirname
RMDIR dirname
Please note that in all cases the filename/dirname is a full directory path, not
just the last component of the full path. File changes caused by mmap are
currently only detected for x86, IA64, and x86-64.
If you want to use fschange, download the stuff below, apply the patch to
your kernel, run "make oldconfig", select "M" or "Y" when asked whether you
want fschange support. Then rebuild and install your new kernel. Depending on whether
you selected "M" or "Y", you will either see the /proc/fschange interface directly
after your system has rebooted or after you have loaded the fschange kernel module.
This program can be used to emulate fschange on a system that
only supports inotify. It scans the file system, registering for
changes in all directories, and prints all file system events in the
fschange event format to stdout or a user-defined log file.
This patch introduces new fschange features. When in-memory buffers are full,
parts of the in-memory information are compressed (using the kernel ZLIB implementation)
in order to make some space for further file events. They are decompressed later on when
a process wants to read them through the proc file. This allows to store more events in
the kernel buffers, while keeping memory consumption low. When all compressed buffers are
full, a new file system event "ERROR buffers full" is created.