On Thu, Jan 23, 2003 at 10:55:12AM -0500, Hal Roberts wrote: > 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.
Great detective work ! Actaully this is a bug in IIS. The protocol states that STATUS_NOTIFY_ENUM_DIR is a valid return, if too many files were changed (hmmm. define "too many" :-). It would be possible to cause this to break on Windows 2000 servers also, but I imagine that under 'normal' circumstances few enough files have changed that this doesn't cause a problem for IIS. I'll have to think on this some more.... Thanks a *lot* for tracking this down ! Jeremy.