1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071 |
- Linux Directory Notification
- ============================
- Stephen Rothwell <sfr@canb.auug.org.au>
- The intention of directory notification is to allow user applications
- to be notified when a directory, or any of the files in it, are changed.
- The basic mechanism involves the application registering for notification
- on a directory using a fcntl(2) call and the notifications themselves
- being delivered using signals.
- The application decides which "events" it wants to be notified about.
- The currently defined events are:
- DN_ACCESS A file in the directory was accessed (read)
- DN_MODIFY A file in the directory was modified (write,truncate)
- DN_CREATE A file was created in the directory
- DN_DELETE A file was unlinked from directory
- DN_RENAME A file in the directory was renamed
- DN_ATTRIB A file in the directory had its attributes
- changed (chmod,chown)
- Usually, the application must reregister after each notification, but
- if DN_MULTISHOT is or'ed with the event mask, then the registration will
- remain until explicitly removed (by registering for no events).
- By default, SIGIO will be delivered to the process and no other useful
- information. However, if the F_SETSIG fcntl(2) call is used to let the
- kernel know which signal to deliver, a siginfo structure will be passed to
- the signal handler and the si_fd member of that structure will contain the
- file descriptor associated with the directory in which the event occurred.
- Preferably the application will choose one of the real time signals
- (SIGRTMIN + <n>) so that the notifications may be queued. This is
- especially important if DN_MULTISHOT is specified. Note that SIGRTMIN
- is often blocked, so it is better to use (at least) SIGRTMIN + 1.
- Implementation expectations (features and bugs :-))
- ---------------------------
- The notification should work for any local access to files even if the
- actual file system is on a remote server. This implies that remote
- access to files served by local user mode servers should be notified.
- Also, remote accesses to files served by a local kernel NFS server should
- be notified.
- In order to make the impact on the file system code as small as possible,
- the problem of hard links to files has been ignored. So if a file (x)
- exists in two directories (a and b) then a change to the file using the
- name "a/x" should be notified to a program expecting notifications on
- directory "a", but will not be notified to one expecting notifications on
- directory "b".
- Also, files that are unlinked, will still cause notifications in the
- last directory that they were linked to.
- Configuration
- -------------
- Dnotify is controlled via the CONFIG_DNOTIFY configuration option. When
- disabled, fcntl(fd, F_NOTIFY, ...) will return -EINVAL.
- Example
- -------
- See Documentation/filesystems/dnotify_test.c for an example.
- NOTE
- ----
- Beginning with Linux 2.6.13, dnotify has been replaced by inotify.
- See Documentation/filesystems/inotify.txt for more information on it.
|