Strange oplock behaviour

[Volker Lendecke]

On Tue, Oct 11, 2005 at 11:45:49AM +0200, Beschorner Daniel wrote:
> For many samba releases I have a MS Visual C++ project that is unable to
> compile on a samba share under certain cases:
> 
> W2K SP3, oplocks enabled (on client side) -> works
> W2K SP4, oplocks disabled -> works
> XP RTM, oplocks enabled -> works
> XP SP2, oplocks disabled -> works
> 
> W2K SP4, oplocks enabled -> fails
> XP SP2, oplocks enabled -> fails
> 
> If the precompiled header file is enabled an internal compiler error is
> thrown (you will find reports from others in newsgroups).

Best thing in such a case is to give us two comparative sniffs. Install
ethereal on the client, store the files on a Windows server and compile the
project. Install the files on the Samba server and make it fail.

It is important that the sniffs contain the start of the session, so make sure
that before you start compiling kill the corresponding smbd while ethereal is
already capturing, and have the client automatically reconnect. The same
applies to the sniff against Windows, where you can shutdown the session with
the computer management tools.

You might also provide a debug level 10 log of smbd.  And, it's important to be
as exact as possible about the exact failure timestamp.

Another thing: With 3.0.21 the oplock implementation has changed, we behave a
bit more windows-like wrt level 2 oplocks. You might want to check out the
current SAMBA_3_0 branch from svn and test against that as well, for bugfixing
this is probably even the better option, and it gives the new code probably
some good testing.

All the sniffs become probably large, so best would be an archive on some
webserver.

Thanks,

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20051011/5ccd593d/attachment.bin