Dmitry Matveev <[email protected]> wrote: > > Would be nice to provide a detailed description of what kqueue lacks > > during the early stages of the project. It might be the case that > > it's impossible to extend kqueue to implement some important > > functionality... in which case we could be looking at a different > > project altogether (e.g. implement inotify in the kernel)! > > I have found that kqueue does not have analogues to the following > inotify events: > > 1. IN_ACCESS - File was read from > 2. IN_OPEN - File was opened > 3. IN_CLOSE_WRITE - File was closed (and was open for writing) > 4. IN_CLOSE_NOWRITE - File was closed (and was not open for writing) > 5. IN_MOVED_FROM - File was moved away from a watched directory > 6. IN_MOVED_TO - File was moved into a watched directory > > There is also the IN_UNMOUNT event. According to manual, kqueue has > the NOTE_REVOKE event to signal that the underlying fileystem was > unmounted, but I could not reach this behaviour. The fact that > kqueue requires an open file descriptor per entry complicates the > monitoring on removable devices. > > Inotify also provides an additional information for several > notifications, i.e. for MOVED_FROM/MOVED_TO events it also supplies > a name of the file moved. Technically for kqueue this information > can be passed from kernel via kevent.data (if to consider this field > as a pointer). > > Determining the possibility of extending kqueue with this additional > functionality requires a deeper analysis, I have planned it on the > community bonding period.
Solaris has Event Port interface, an equivalent of inotify, which has mentioned capabilities. I would suggest to evaluate its interface: http://blogs.sun.com/praks/entry/file_events_notification (see man pages as well) Having it in the kernel - might be something to consider. Also, AFAIK, GIO already has support for it. -- Mindaugas
