| 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 | |
| ------- | |
| #define _GNU_SOURCE /* needed to get the defines */ | |
| #include <fcntl.h> /* in glibc 2.2 this has the needed | |
| values defined */ | |
| #include <signal.h> | |
| #include <stdio.h> | |
| #include <unistd.h> | |
| static volatile int event_fd; | |
| static void handler(int sig, siginfo_t *si, void *data) | |
| { | |
| event_fd = si->si_fd; | |
| } | |
| int main(void) | |
| { | |
| struct sigaction act; | |
| int fd; | |
| act.sa_sigaction = handler; | |
| sigemptyset(&act.sa_mask); | |
| act.sa_flags = SA_SIGINFO; | |
| sigaction(SIGRTMIN + 1, &act, NULL); | |
| fd = open(".", O_RDONLY); | |
| fcntl(fd, F_SETSIG, SIGRTMIN + 1); | |
| fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT); | |
| /* we will now be notified if any of the files | |
| in "." is modified or new files are created */ | |
| while (1) { | |
| pause(); | |
| printf("Got event on fd=%d\n", event_fd); | |
| } | |
| } |