Wingolog.org Website Review

Let's say you decide that you'd like to see what some other processes on your system are doing to a subtree of the file system. You don't want to have to change how those processes work -- you just want to see what files those processes create and delete. One approach would be to just scan the file-system tree periodically, enumerating its contents. But when the file system tree is large and Fortunately, Linux provides an API to allow a process to receive notifications on file-system change events, called inotify. So you > With careful programming, an application can use inotify to > efficiently monitor and cache the state of a set of filesystem > objects. However, robust applications should allow for the fact that > bugs in the monitoring logic or races of the kind described below > may leave the cache inconsistent with the filesystem state. It is > probably wise to do some consistency checking, and rebuild the cache It's not exactly reas*uring is it? I mean, you had one job and all. Reading down a bit farther, I thought that with some careful programming, I could get by. After a day of trying, I am now certain that it is impossible to build a correct recursive directory monitor with inotify, and I am not even sure that good enough solutions Fundamentally, inotify races the monitoring process with all other processes on the system. Events are delivered to the monitoring process via a fixed-size buffer that can overflow, and the monitoring process provides no back-pressure on the system's rate of filesystem modifications. With inotify, you have to be ready to lose events. This I think is probably the easiest limitation to work around. The kernel can let you know when the buffer overflows, and you can tweak the buffer size. Still, it's a first indication that perfect is not possible. You go to open the file -- but is it still there? By the time you get around to looking for it, it could have been deleted, or renamed, or