diff options
Diffstat (limited to 'Documentation/filesystems/dnotify.txt')
| -rw-r--r-- | Documentation/filesystems/dnotify.txt | 70 |
1 files changed, 0 insertions, 70 deletions
diff --git a/Documentation/filesystems/dnotify.txt b/Documentation/filesystems/dnotify.txt deleted file mode 100644 index 15156883d321..000000000000 --- a/Documentation/filesystems/dnotify.txt +++ /dev/null @@ -1,70 +0,0 @@ - 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 tools/testing/selftests/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. |