Bug report for Samba 2.0.7

[Nick Barker]

Samba Team,

Samba v2.0.7

I believe that there is a problem with the way that blocking locks are
implemented:

File source/smbd/reply.c


The documentation for blocking locks suggests that where a timeout is given,
and the lock request cannot be immediately granted then the lock request
will be blocked.

Behaviour in 'reply_lockingX' seems to be OK, as a timeout parameter is
passed.

However in 'reply_lockread' and 'reply_lock', WE assume an indefinate
timeout, and the request can potentially NEVER return. As a timeout value
was not passed to these functions, I believe that it is innapropriate to
assume that the client wants to block until the lock becomes available, and
should return the lock error immediately.


My rationale:
I have been trying to get an application to run which seems to rely on
lockread requests failing immediately. The applications runs on a mixed
network of W95/98 and NT. Interestingly the W95/98 clients run successfully,
but clients of the same application don't work on NT platforms - unless they
are the first client to start up the application!!.

The application is called Vista, and it seems to be built upon foxpro. I
don't know if it is the application or foxpro which is exibiting the
behaviour described below, but it may be of use to others who might be
having problems with foxpro over samba.

The application seems to mantain a single file which records the number of
current clients through writelocking regions of the file. When the
application starts it attempts to lock the first 10 bytes of the file, and
if fails it tries the next 10 bytes and so on until it finds a free slot.

Following debug output, it transpires that W95/98 clients make a lockingX
request with a zero timeout to achieve this behaviour, and reply_lockingX
behaves in an appropriate way by not blocking and returning the error
immediately.

However NT clients try to achieve the same thing through calls to lockread,
and of course with blocking locks turned on, we block these calls
indefinately. Consequence, the NT client will only work as long as it can
get the very first slot, ie be the first client to start up the application.

Disabling the blocking locks option entirely resolves these issues, but of
course that then stops propper blocking lock requests coming through
'lockingX' from working as well.

I therefore suggest that the code which pushes the lock request onto the
blocking queue in reply_lockread and reply_lock is removed, and that the
default behaviour for these two functions is always to return the lock fail
immediately. Leave the lock blocking stuff to lockingX which has the
appropriate parameters to intelligently decide if it is a blocking lock
request (i.e. a timeout).

Hope this is of use, and if you need any further clarification please get in
touch

Regards
Nick Barker

Nick.Barker at durham.ac.uk