There are a number of advantages when using inotify when compared to the older
dnotify API that it replaced. With dnotify, a program had to use one
file descriptor for each directory that it was monitoring. This can become a bottleneck since the limit of file descriptors per process could be reached. Later, fanotify was created to overcome this issue. The use of file descriptors along with dnotify also proved to be a problem when using removable media. Devices could not be unmounted since file descriptors kept the resource busy. Another drawback of dnotify is the level of granularity, since programmers can only monitor changes at the directory level. To access detailed information about the environmental changes that occur when a notification message is sent, a stat structure must be used; this is considered a necessary evil in that a cache of stat structures has to be maintained, for every new stat structure generated a comparison is run against the cached one. The inotify API uses fewer file descriptors, allowing programmers to use the established select and poll interface, rather than the signal notification system used by
dnotify. This also makes integration with existing select- or poll-based libraries (like
GLib) easier. == See also ==