File locking problems

[malcolm]

More tests
client 1 (Windows) 
	client 2 (Windows)
		client 3 (Linux)
O.K.
It seems that if a single Windows client has a lock on a file, it tries to 
prevent other client programs from opening the same file. 

Could this be a problem with opportunistic locking on the Windows side? Not 
that this is enabled in the registry (unless this is default and one must 
explicitly disable it).

Malcolm

On Thursday 19 May 2005 14:13, malcolm wrote:
> I have been writing some code to perform portable file locking between
> Linux and Windows. On Windows I use UnlockFileEx() and Linux fcntl(). To
> get over the incompatibilites between these calls, I use the calls to lock
> the first two bytes of the file with a read lock. The first byte is
> regarded as meaning that the file is read locked and the second byte that
> the file is write locked. The Linux side is routine but the Windows side is
> somewhat more difficult. If I want a read lock I test if I can get a write
> lock on the second byte. If successful then I release the lock obtained and
> set a read lock on the first byte. To obtain a write lock, I test whether I
> can set a write lock on both bytes, release this write lock and set a read
> lock on the second byte.
>
> This works correctly for a samba share for the cases when client 1 and
> client 2 are either both Linux or both Windows, or client 1 is Linux and
> client 2 is Windows. But if the order is changed and client 1 is Windows
> and client 2 is Linux, the open() call on Linux fails with EAGAIN. So I
> tried putting the open() call in a "for ( tries = 0 ; tries  < 100 :
> tries++ )" loop with a wait of usleep( 100 ) after each open() attempt. And
> bingo, this works with about 4 or 5 loops. Untill I discovered that when
> the delay between starting client 1 (Windows) and client 2 (Linux) is more
> than a couple of minutes (rather than seconds) then the open loop usually
> fails even after 1000 iterations.
>
> In smb.conf I have:
> 	locking = Yes
>         posix locking = Yes
>         strict locking = No
>         kernel oplocks = Yes
>         blocking locks = No
>
> Changing any of these means that nothing works.
>
> The version of SAMBA is:
> 	Version 3.0.13-1.1-SUSE
> Windows is XP Proffesional
>
> Any help gratefully received.
>
> Malcolm Agnew