Hi All, I am experiencing issues with the use of DBase files on a Samba 2.0.5a share, that appear to be due to locking problems. Basically, I have test programs for both DOS and Win32 that does nothing but append records to a DBase database (DBF/MDX files). If more than one client PC is appending to this file, data loss occurs. I get random data loss, with records lost, and index file corruption too. I.e. I find records that were supposedly added that are simply missing, and other records that have multiple index file entries pointing to one physical record - and the record contains only the data from one PC of course. FYI, I've written the test apps using several different methods of DBase access - CodeBase 5.1 for DOS and Win32, as well as Borland C++ Builder 4.0 and the "Borland Database Engine". The problem ONLY seems to occur when two clients systems are WRITING to the database at the same time. I can have one reading from, while another writes to the database, and not see the problem. I've tried turning STRICT LOCKING on, and OPLOCKS off, to no avail. I found references in the Samba mailing list archives to a Redhat 6.0 GLIBC locking bug. The two Samba servers I've seen the problem on are both running Redhat 6.0, with all the latest updates applied. I built the Samba 2.0.5a RPM's myself, using the samba-2.0.5a.tar.gz source. So my question is: is this locking bug in the Redhat C libraries fixed in Samba 2.0.5a, or do I need to do something to upgrade my C libraries? Or is something else going on? Thanks! -- /------------------------------------------------\ | Jim Morris | Business: jmorris@rtc-group.com | | | Personal: Jim@Morris.net | |------------------------------------------------| | World Wide Web: http://Jim.Morris.net | | AOL Instant Messenger: JFM2001 | \------------------------------------------------/
Are you sure it's not a problem rather with the DBase engine failing to lock the records properly, for whatever reason? That's how FoxPro works, anyhow, where the files live on a Novell share, and FoxPro isn't all that different from DBase (or, didn't used to be, anyhow). Jim Morris wrote:> > Hi All, > > I am experiencing issues with the use of DBase files on a Samba 2.0.5a > share, that appear to be due to locking problems. Basically, I have > test programs for both DOS and Win32 that does nothing but append > records to a DBase database (DBF/MDX files). If more than one client > PC is appending to this file, data loss occurs. I get random data > loss, with records lost, and index file corruption too. I.e. I find > records that were supposedly added that are simply missing, and other > records that have multiple index file entries pointing to one physical > record - and the record contains only the data from one PC of course. > FYI, I've written the test apps using several different methods of > DBase access - CodeBase 5.1 for DOS and Win32, as well as Borland > C++ Builder 4.0 and the "Borland Database Engine". > > The problem ONLY seems to occur when two clients systems are WRITING > to the database at the same time. I can have one reading from, while > another writes to the database, and not see the problem. > > I've tried turning STRICT LOCKING on, and OPLOCKS off, to no avail. > > I found references in the Samba mailing list archives to a Redhat 6.0 > GLIBC locking bug. The two Samba servers I've seen the problem on are > both running Redhat 6.0, with all the latest updates applied. I built > the Samba 2.0.5a RPM's myself, using the samba-2.0.5a.tar.gz source. > > So my question is: is this locking bug in the Redhat C libraries > fixed in Samba 2.0.5a, or do I need to do something to upgrade my C > libraries? Or is something else going on? > > Thanks! > -- > /------------------------------------------------\ > | Jim Morris | Business: jmorris@rtc-group.com | > | | Personal: Jim@Morris.net | > |------------------------------------------------| > | World Wide Web: http://Jim.Morris.net | > | AOL Instant Messenger: JFM2001 | > \------------------------------------------------/-- Matthew Vanecek Course of Study: http://www.unt.edu/bcis Visit my Website at http://people.unt.edu/~mev0003 For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something...
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@rtc-group.com |
| | Personal: Jim@Morris.net |
|------------------------------------------------|
| World Wide Web: http://Jim.Morris.net |
| AOL Instant Messenger: JFM2001 |
\------------------------------------------------/