DBase File locking issues (PR#20441)

[Jeremy Allison]

Jim at Morris.net wrote:

> I have finally tracked down the reason I am experiencing problems with
> DBase files on Samba file servers - initially Redhat 6, and now on
> Caldera OpenLinux 2.2 as well.

Great debugging work !

> The DOS client code uses a DBase library called CodeBase to access the
> DBase files.  When a record is appended to a file, the underlying C
> code does the following at the beginning of the append operation:
> 
>         rc = lock( file->hand, pos_start, num_bytes ) ;
> 
> At the the time of the call:
> 
>    file->hand = A valid file handle
>    pos_start  = 0xEFFFFFFF

The pos_start is probably the problem. On Win32 this is an unsigned
32 bit number. On POSIX (Samba) lock calls treat this as a signed
32 bit number. Samba on a 32 bit system such as Linux does some
lock mangling to move this into the POSIX range. It should work.

> The same test against the Samba 2.0.5a server(s) shows that the lock()
> call ALWAYS returns a 0 (zero) status - even if a different PC already
> has a lock!

Hmmm. But it obviously doesn't :-(.

> The Win32 library code for this same operations uses a call to the
> Win32 library function LockFile(), like this:
> 
>    if ( LockFile( (HANDLE)file->hand, pos_start, 0, num_bytes, 0 ) )
>       rc = NO_ERROR ;
>    else
>       rc = GetLastError() ;
> 
> This code under Win32 appears to always obtain the requested lock as
> well, regardless of whether another PC currently has the lock.
> 
> The DOS test program for this has been run from systems using MS-DOS
> 6.22, PC-DOS 6.x, Win98 DOS Box, and WinNT 4.0sp/sp5.  The Win32
> code has been tested on Win98 and WinNT 4.0sp3/sp5.

Thanks for this analysis. I will test this with a Win32 program
to check the Samba locking with this lock range on both 64 bit (IRIX)
and 32 bit (Linux) systems.

> I suspect that the problem may be that Samba things the lock is bogus,
> since it is past the end of the actual file, and not bother to keep
> track of the lock from two different clients.  However, if I run two
> copies of the test program on the SAME PC, then the lock works.  So it
> does appear that the smbd process for the specific client machine *IS*
> tracking the lock - but it is not bothering to communicate the
> existence of the lock to other running smbd processes.

Nah. Actually the Win32 client redirector is doing the lock
conflict detection locally in this case. That's why it needs
to be done from two different machines.

I'll code this up (Win32) and test it against the current CVS stable
tree, and get back to you on this.

Thanks for all the analysis,

Cheers,

	Jeremy Allison,
	Samba Team.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------