| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 		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 | 
					
						
							|  |  |  | ------- | 
					
						
							| 
									
										
										
										
											2010-03-10 15:21:57 -08:00
										 |  |  | See Documentation/filesystems/dnotify_test.c for an example. | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-03-10 15:21:57 -08:00
										 |  |  | NOTE | 
					
						
							|  |  |  | ---- | 
					
						
							|  |  |  | Beginning with Linux 2.6.13, dnotify has been replaced by inotify. | 
					
						
							|  |  |  | See Documentation/filesystems/inotify.txt for more information on it. |