[EMAIL PROTECTED] wrote:
So if I'm understanding you correctly this is actually a kernelNo it's Samba receiving a signal from the kernel, but not processing it further inside Samba.
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.
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.
So I think Samba forgets to call process_pending_change_notify_queue() after a copy operation,
so a Windows application waiting for a change notification doesn't get noticed or only after some
time when other file operations triggered the process_pending_change_notify_queue() call.
...Juergen
