locking bug in libsmb/clientgen.c ???

[Andrew Tridgell]

> - "error: lock3 0 succeeded" in smbtorture's run_locktest3

you probably shouldn't use smbtorture as a guide to what is causing
real-world locking problems. smbtorture is there as a reminder to us
that smbd doesn't perform exactly to spec on file locking tests, but
as far as we know these particular problems don't affect real
applications using any of Microsofts clients. That's because MS
clients heck for things like a inter-PID intra-client locking conflict
and flag it internally so that it never goes over the wire to the
server. It would be nice for Samba to get this right itself, but we
believe it will make no difference with any MS client. (also note that
NT4 and Win9X fail some of the tests in smbtorture as well, it is
quite a strict tester).

> I've looked at cli_lock and cli_unlock in libsmb/clientgen.c, and I cannot
> see any locking allow/disallow intelligence.

that's right. Remember that clientgen.c is used by smbclient not smbd
I know that's not strictly true, it's used in the browse client and
security server code, but for the purposes of this discussion you
could consider it true. So if you want to fix a problem noticed by a
user using smbd then don't look at clientgen.c :)

To actually "fix" the locking bugs pointed out by smbtorture we will
need to bypass the normal unix fcntl() lock interface and have our own
lock daemon. We want to do this anyway for other reasons (mostly to do
with 32/64 bit lock offsets) but it isn't a really high priority as we
know of no current application problems that can be caused by the
current mechanism. This makes it a "we want to do this right
eventually" problem rather than a "oh shit, we better fix this today"
problem :)

> PROBLEM
> -------
>
> - complaints of file corruption when multiple users access files
>  simultaneously

we would need some more info about this. Is there any chance it can be
explained by normal oplock behaviour?