100 lines
3.5 KiB
Plaintext
100 lines
3.5 KiB
Plaintext
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);
|
|
}
|
|
}
|