SMBtrans2 oplock safety

[Lev Iserovich]

Hi all,

I've encountered a problem in a win2k machine communicating with a samba 
2.2.5 server.
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 
path_info query.
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.

Thanks,

--Lev