Inotify: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m →‎See also: revert - dnotify is already mentioned in the article
some events seemed invalid on my system (2.6.20-gentoo-r8)
Line 66: Line 66:
* <tt>IN_OPEN</tt> and <tt>IN_CLOSE</tt> - open or close of file
* <tt>IN_OPEN</tt> and <tt>IN_CLOSE</tt> - open or close of file
* <tt>IN_MOVED_FROM</tt> and <tt>IN_MOVED_TO</tt> - when the file is moved or renamed
* <tt>IN_MOVED_FROM</tt> and <tt>IN_MOVED_TO</tt> - when the file is moved or renamed
* <tt>IN_DELETE</tt> - a file/directory deleted
* <tt>IN_CREATE_SUBDIR</tt> and <tt>IN_DELETE_SUBDIR</tt> - create or delete of directory
* <tt>IN_CREATE_FILE</tt> and <tt>IN_DELETE_FILE</tt> create or delete file in a directory
* <tt>IN_CREATE</tt> and <tt>IN_DELETE</tt> create or delete a file/directory
* <tt>IN_DELETE_SELF</tt> - file monitored is deleted
* <tt>IN_DELETE_SELF</tt> - file monitored is deleted
* <tt>IN_UNMOUNT</tt> - when the device where the file is stored is unmounted


== History ==
== History ==

Revision as of 22:03, 1 August 2007


inotify is a Linux kernel subsystem that provides file system event notification. It was written by Robert Love and John McCutchan to replace dnotify. It was included in the mainline kernel from release 2.6.13, and could be compiled into 2.6.12 and possibly earlier releases by use of a patch. Its function is essentially an extension to filesystems to notice changes to the filesystem, and report those changes to applications.

Its major use is therefore arguably in desktop search utilities like Beagle, where its functionality permits reindexing of changed files without scanning the filesystem for changes every few minutes, which would be very inefficient. By being told that a file has changed directly by the kernel, rather than actively looking, Beagle and such utilities can achieve change-to-reindexing times of only about a second, with very small performance hits (inotify therefore enables the use of such programs in a sensible manner; daemons are generally not accepted by distributors if they drain system performance noticeably to provide userland functionality.)

It can also be used to automatically update directory views, reload configuration files, log changes, backup, synchronize, and upload.

Advantages

Inotify has many advantages over dnotify, the module that it replaced. With the older module, 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 descriptor per process can be reached. The use of file descriptors along with dnotify proved to be a problem when using removable media. Devices couldn't be unmounted since file descriptors kept the resource busy.

Another drawback of dnotify, is the level of granularity since you can only monitor changes at the directory level. To get more information about the exact changes that happened when you get a notification you need to use a stat structure. Programmers are forced to keep a cache of stat structures and when a change is made to the files within a directory a new stat structure needs to be generated and compared against the cached one.

Inotify uses a simple and elegant API that uses minimal file descriptors allowing programmers to use the select and poll interface that they are more comfortable with compared to the signal notification system used by dnotify. It also makes integration with existing select- or poll-based libraries (like GLib) easier. Inotify also provides more granularity than dnotify. The interface to inotify is provided through a node.

Disadvantages

Inotify has no ability to set recursive watches on a particular point in the file system. This has led to a number of user-space libraries that attempt to emulate this functionality. The technique to emulate recursive watches usually involves recursively scanning a directory tree, adding watches for each directory found, then adding new watches as directories get created, and removing watches as directories disappear.

However, a rapid succession of directories being created can cause a library responding to inotify events to "get its watches out of sync" with the actual directory contents. When directory A is created, and then directory B is created under A, the time lapse between the two operations may be shorter than the time the user-space inotify library takes to set a watch on A (which would allow it to notice the creation of B). Therefore, creation of B is missed. Recursively scanning A may help, but it only minimizes the window of opportunity for this particular race condition.

This race condition is, therefore, unavoidable.

How it works

Inotify is used through a series of system calls specifically created for inotify.

int inotify_init ()

Creates an inotify instance. Returns a file descriptor which all events are read from.

int inotify_add_watch (int fd, const char* pathname, int mask)

Starts watching the inode pointed to by pathname for events contained in mask. Returns a watch descriptor which is unique (within this inotify instance) to the inode pointed to by the pathname (NOTE: Multiple pathnames can point to the same inode/watch descriptor).

int inotify_rm_watch (int fd, int wd)

Cancels a watch on the given watch descriptor.

Events generated by inotify contain the following information:

Identifier Contents
wd watch descriptor
mask event tag
cookie cookie used to synchronize between IN_MOVED_FROM and IN_MOVED_TO
len length of name field
name the (optional) filename associated with this event (local to parent directory)

Some of the events that can be monitored for are:

  • IN_ACCESS - last access of the file
  • IN_MODIFY - last modification
  • IN_ATTRIB - attributes of file change
  • IN_OPEN and IN_CLOSE - open or close of file
  • IN_MOVED_FROM and IN_MOVED_TO - when the file is moved or renamed
  • IN_DELETE - a file/directory deleted
  • IN_CREATE and IN_DELETE create or delete a file/directory
  • IN_DELETE_SELF - file monitored is deleted

History

See also

External links