Linux provides another mechanism for monitoring file events. This mechanism, known as dnotify, has been available since kernel 2.4, but has been made obsolete by inotify. The dnotify mechanism suffers a number of limitations compared with inotify:
The dnotify mechanism provides notification of events by sending signals to the application. Using signals as a notification mechanism complicates application design (Interprocess Communication with Signals). It also makes the use of dnotify within a library difficult, since the calling program might change the disposition of the notification signal(s). The inotify mechanism doesn’t use signals.
The monitoring unit of dnotify is a directory. The application is informed when an operation is performed on any file in that directory. By contrast, inotify can be used to monitor directories or individual files.
In order to monitor a directory, dnotify requires the application to open a file descriptor for that directory. The use of file descriptors causes two problems. First, because it is busy, the file system containing the directory can’t be unmounted. Second, because one file descriptor is required for each directory, an application can end up consuming a large number of file descriptors. Because inotify doesn’t use file descriptors, it avoids these problems.
The information provided by dnotify about file events is less precise than that provided by inotify. When a file is changed inside a monitored directory, dnotify tells us that an event has occurred, but doesn’t tell us which file was involved in the event. The application must determine this by caching information about the directory contents. Furthermore, inotify provides more detailed information than dnotify about the type of event that has occurred.
In some circumstances, dnotify doesn’t provide reliable notification of file events.
Further information about dnotify can be found under the description of the F_NOTIFY operation in the fcntl(2) manual page, and in the kernel source file Documentation/dnotify.txt.