file change notification issues

[jra at dp.samba.org]

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.