Why Not dnotify and Why inotify Everyone seems quick to deride the blunder known as "dnotify" and applaud a replacement, any replacement, man anything but that current mess, but in the name of fairness I present my treatise on why dnotify is what one might call not good: * dnotify requires the opening of one fd per each directory that you intend to watch. o The file descriptor pins the directory, disallowing the backing device to be unmounted, which absolutely wrecks havoc with removable media. o Watching many directories results in many open file descriptors, possibly hitting a per-process fd limit. * dnotify is directory-based. You only learn about changes to directories. Sure, a change to a file in a directory affects the directory, but you are then forced to keep a cache of stat structures around to compare things in order to find out which file. * dnotify's interface to user-space is awful. o dnotify uses signals to communicate with user-space. o Specifically, dnotify uses SIGIO. o But then you can pick a different signal! So by "signals," I really meant you need to use real-time signals if you want to queue the events. * dnotify basically ignores any problems that would arise in the VFS from hard links. * Rumor is that the "d" in "dnotify" does not stand for "directory" but for "suck." A suitable replacement is "inotify." And now, my tract on what inotify brings to the table: * inotify's interface is a device node, not SIGIO. o You open only a single fd, to the device node. No more pinning directories or opening a million file descriptors. o Usage is nice: open the device, issue simple commands via ioctl(), and then block on the device. It returns events when, well, there are events to be returned. o You can select() on the device node and so it integrates with main loops like coffee mixed with vanilla milkshake. * inotify has an event that says "the filesystem that the item you were watching is on was unmounted" (this is particularly cool). * inotify can watch directories or files. * The "i" in inotify does not stand for "suck" but for "inode" -- the logical choice since inotify is inode-based.