SMBtrans2 oplock safety
lev at ciprico.com
Fri Jul 19 08:19:02 GMT 2002
I've encountered a problem in a win2k machine communicating with a samba
Sometimes a file open on the win2k machine hangs for 30 seconds, and
then after a message to the samba event log like :
oplock_break: *receive_smb* timed out after 30 seconds.
the open finally goes through.
Doing a lot of network traces revelead the following :
The client requests a file open, while already having the file open, and
holding a batch oplock on the file.
The server sends an oplock_break request to the client. This requests
crosses with a SMBtrans2 QUERY_PATH_INFO request on the same filename on
the wire. The smb server, I believe due to SMBtrans2 being marked as
QUEUE_IN_OPLOCK in smbd/process.c, it is queued until the oplock_break
reply is recieved.
The problem is that for some weird reason, win2k does not seem to want
to acknowledge the oplock_break until it receives the reply to the
I found this because after 30 seconds, samba gives up, breaks the
oplock, and grants the open request. It also replies to the queued
path_info query, right after which the client returns the oplock_break
response (which is too late obviously, and is reported as "oplock_break
reply recieved, but no oplocks granted on this file" in the log.)
I think the only subfunction in SMBtrans2 which depends on not being
called with outstanding oplock breaks is the trans2open function, which
internally already has protection against this situation. Therefore I
think the QUEUE_IN_OPLOCK flag for SMBtrans2 should be removed.
Is this safe to do?
If so, this should be cheked in as it would solve this issue.
More information about the samba-technical