file change notification issues
Hal Roberts
hroberts at cyber.law.harvard.edu
Thu Jan 23 15:56:00 GMT 2003
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
More information about the samba-technical
mailing list