DBase File locking issues

[Jim Morris]

Hi all,

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.

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
   num_bytes  = 1

Test code shows that with a Windows NT file server, if the first PC
has issued the above lock call, the 2nd PC will get a -1 return code,
indicating that the 1 byte region in the file is already locked.
The client code will basically loop, retrying until it gets a 0 return
code, indicating that it now has a lock on the requested region of the
file.

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!

I think that the position requested for the lock is defined by DBase
standards, and basically is used to lock the "end" of the file, for
the append operation.  The Codebase libraries indicate that if
another arbitrary position is locked for the append (2000000000L for
example), then DBase IV compatibility will be lost.

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.

Once again, the above code works using Windows NT 4.0 or Win98 as the
server.

The test code has a loop, that has a getch(), a call to lock(),
another getch(), and a call to unlock().  This way, I can run two
copies, let one do the lock(), then hit a key to have the 2nd
program/client try to lock the record.

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.

I will look at the code for samba if I get time. I hope these details
help someone on the Samba team to duplicate (and hopefully fix!) the
problem...
 --
/------------------------------------------------\
| Jim Morris  | Business:  jmorris at rtc-group.com |
|             | Personal:  Jim at Morris.net        |
|------------------------------------------------|
|    World Wide Web:  http://Jim.Morris.net      |
|       AOL Instant Messenger:  JFM2001          |
\------------------------------------------------/