op-lock weirdness with winXP and ntvfs_cifs

[Amin Azez]

I'm using samba4 for compression and caching (as said before) and am
just working op-lock compliance into the code.

I notice "striking" behaviour on the part of a windows XP client I am
testing with.

(I have cygwin installed to make testing easier)


I notice these characteristics of the winXP box, which (under cygwin) is
doing:
# read p < /cygdrive/u/test.txt
so it just reads a 4K block from the samba proxy.

1. It opens the file twice,
* once without any oplock flags and then it immediately closes
* once with: NTCREATEX_FLAGS_REQUEST_OPLOCK |
NTCREATEX_FLAGS_REQUEST_BATCH_OPLOCK

2. after it finishes read the file it does not close the file (fair
enough, I guess thats BATCH_OPLOCK for you?)

3. If I repeat the command (or with a different file) it first closes
the open file.

4. If I repeat the command and I then try and read the same file from a
unix machine using smbclient, then smbclient hangs - waiting for the
oplock to be broken I guess. This takes some time. No oplock-break
requests via the proxy to winXP have been noticed yet by me, I may need
to look deeper though, but its not chowing up in the vfs_cifs.c oplock
handler.

5. If I while the smbclient read is waiting, I repeat the cygwin read on
the same file, then it immediately kicks the smbclient process into
action. smbclient opens first, and then cygwin opens. This suggests that
the close event to windows server 2003 triggerred a waiting open; but
see next point:

6. However if while smbclient is waiting, I make cygwin open a different
file (so it closes the file smbclient wants) then smbclient still hangs.
The only way to kick smbclient is to have cygwin open and close the file.

So this leaves me wondering why the windows 2003 server that I am
proxying is not propagating the oplock break request to the windows client.

I'll report back when I know more, but tips would be appreciated.

Sam