file change notification issues

[Hal Roberts]

The purpose of this mail is to make sure no one else is working on / has already finished hacking samba's file change notification support to support notification of individual file changes. If not, I plan on doing so forthwith.

More details:

I've been wrestling with samba for the past couple of weeks trying to get it to play nicely with IIS. I've got IIS running with a samba share as the root directory, and everything works well except for asp caching. When running from a samba share, IIS refuses to invalidate any cached asps, even if the cached asp is modified or even deleted or moved.

I've finally pegged the problem as samba file change notification support. The cifs reference at:

http://www.snia.org/tech_activities/CIFS/

indicates that samba should send back information about which files triggered a notification and why for any directory with notification running (for instance, /test/test.asp and FILE_ACTION_MODIFIED). Samba should send back a list of such file/action records with one record for each file action that triggered the notification, up to the maximum as determined by the parameter count field in the request. If the number of records would be greater that the max allowed, the samba server should return a STATUS_NOTIFY_ENUM_DIR error.

The samba notification stuff as written does not keep track of which specific files were changed and just *always* returns the STATUS_NOTIFY_ENUM_DIR error. This approach seems to work fine for handling windows explorer updates, but IIS and presumably other applications just drop these replies as errors.

I hacked the notify stuff to return a hard coded file / action record of a file I knew I was changing to test this theory, and the hack did indeed fix the problem -- when I changed the hard coded file, IIS immediately invalidated the asp cache for that file and loaded up the new file instead.

The big cost of adding individual file notifications will be the need to keep a bunch of file information in memory somewhere. The current code just does a checksum of the file modification times of the monitored directory or relies on the dnotify kernel stuff, which only alerts on whole directories. To figure which file changed, the system will have to keep the state of the monitored files in memory. There is a project called fam (http://oss.sgi.com/projects/fam/) that implements a daemon that handles this sort of thing for the general case, but it does not support all of the notifications that cifs requires (it does not support notifications of file access, for example), so the only way of implementing this correctly seems to be to write it from scratch.

Thoughts?

-hal