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@durham.ac.uk