It seems that change notify is not set up correctly. I'v written an Windows Application running in Windows XP to detect filesystem changes. Basicly this is the Windows code: HANDLE hDirectory = CreateFile(Path, GENERIC_READ | FILE_LIST_DIRECTORY, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL); ... if (ReadDirectoryChangesW(hDirectory, Buffer, BufferSize, TRUE, FILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_DIR_NAME | FILE_NOTIFY_CHANGE_ATTRIBUTES | FILE_NOTIFY_CHANGE_SIZE | FILE_NOTIFY_CHANGE_LAST_WRITE | FILE_NOTIFY_CHANGE_LAST_ACCESS | FILE_NOTIFY_CHANGE_CREATION | FILE_NOTIFY_CHANGE_SECURITY, &BufferReadSize, NULL, FileIOCompletionRoutine)) { ... } Recursive Flag (4th argument) is enabled. Lets say, there is a windows change notify set up for the directory "/home/myname" (accessed by \\MyServer\myname or as a mapped network drive). If I create/change files/directories in that root directory with Putty for example (on Linux system), Windows will get notified about that changes. But as soon as I do the same in one of the sub directories of "/home/myname/" like "/home/myname/test/" no notification is sent. Creating a file in \\MyServer\myname\test however from within windows will create a change notification as expected. I tried the same in Linux by creating a small app to test inotify. Here everything works as expected too. int fds = inotify_init(); int watchds = inotify_add_watch(fds, "/home/myname", IN_MODIFY | IN_ATTRIB | IN_MOVED_FROM | IN_MOVED_TO | IN_DELETE | IN_CREATE); struct inotify_event* event = malloc(1024); while (read(fds, event, 1024) > 0) { printf("Event %x occured in \"%s\"", event->mask, event->name); } So there mustbe some bug within Samba implementation. I'm running a 3.5.4 Samba Server on a Debian 5.0.5 (Lenny) with following configuration: [global] workgroup = MYWKGRP server string = Development Server obey pam restrictions = Yes passdb backend = tdbsam pam password change = Yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . unix password sync = Yes client NTLMv2 auth = Yes syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 min protocol = LANMAN1 load printers = No dns proxy = No ldap ssl = no panic action = /usr/share/samba/panic-action %d create mask = 0775 block size = 8192 change notify = yes interfaces = eth0 [homes] comment = Home Directory for %U valid users = %S read only = No acl group control = Yes create mask = 0777 directory mask = 0777 inherit permissions = Yes inherit acls = Yes browseable = No
Tried your test program, does not work recursively for me. If I run it and to a mkdir /home/myname/x I get output, if I do a mkdir /home/myname/x/y nothing happens. Please tell us exactly what you are doing to get recursive inotify behaviour. Closing as WORKSFORME, please re-open when you have the information available.
Created attachment 5926 [details] Windows directory watch application This is a test case for Windows. Thic is a small directory watch application which works recursively.
Created attachment 5927 [details] Linux directory watch using inotify This is a small linux application for watching a specific directory.
Yes, understood. FileChangeNotify (sp?) on Windows *can* work recursively. This should work for all updates within Samba. Samba at this moment relies on inotify to catch the updates that happen out of its reach, i.e. via other protocols like ftp or nfs. What I failed to do is to generate inotify events out of your Linux test program when adding files/directories in a subdir of the directory watched by inotify_add_watch. You claimed that with a single watch you get recursive behaviour. What are the exact steps I have to make to also get this? Thanks, Volker
You are right Volker, it seems that I was mistaken. Recursive watch is not possible in Linux with current inotify implementation which is really very bad! I'll take a look at the inotify source code, I think that supporting recursive change notification shouldn't that much more difficult because it is only a matter of comparing pathnames which should already have been done in current implementation. (At least if we are talking about general case (links excluded)) Non-Recursive change notification doesn't make much sense especially if we are talking about features like "Windows offline files" to handle some 100000 files.
OK it seems that some one is already working on that issue by creating a linux kernel patch for fsnotify/inotify implementation. See following archive: http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-02/msg05052.html http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-02/msg05055.html He introduced a new IN_TREE/FS_EVENT_ON_TREE flag to support notification of child/descendants. So all what Samba team could do is to be prepared for that changes which will hopefully be in official linux kernel source soon :)