On Tue, Jan 14, 2003 at 07:49:48AM +0100, Juergen Hasch wrote: > [EMAIL PROTECTED] wrote: > > >So if I'm understanding you correctly this is actually a kernel > >bug - correct ? > > > >Can you point me at the areas in the kernel source where the problem > >occurs so I can see how to make smbd work around it until we get the > >kernel fixed. > > > > > > > No it's Samba receiving a signal from the kernel, but not processing it > further inside Samba. > > In notify_kernel/signal_handler() signals_received gets increased when a > change notification > is received from the kernel. Now the change notification for this type > of event (e.g. copy/ > rename/delete...) needs to be processed inside Samba. > This is done in process_pending_change_notify_queue() which is called > from a few places > inside e.g. reply.c. > This is not happening for file copy in my test setup here (using the > copy command in windows). > This means the kernel change notification is no longer active for this > type of event, because it > needs to be restarted in notify_kernel.c/kernel_register_notify(). > > Eventually process_pending_change_notify_queue() is called by chance and > the received > change notification signal gets processed at a later random time.
Well it's not called 'by chance'. It's called once smbd gets back to the main loop should notice in the next select that a changenotify has occurred (the select should return -1, errno == EINTR and then the function async_processing() should be called before the next smbd is processed. Can you send me a debug level 10 please of the operation failing, plus an *exact* method of duplicating it (client OS, smb.condf, exact client windows open and what you do to reproduce it). Thanks, Jeremy.