Fix for multi-user database corruption problems just checked in.

[William Jojo]

Jeremy,

Tested the code...I did notice the change, it was obvious what you're
doing...Our problem still exists, however. There is a log level 10 at:

http://www.hvcc.edu/~jojowil

with your name on it!

It appears that it has to do with file "searching"...IOW like it's trying
to find a DLL on the served share where Access actually lives. I verified
this by creating the DB on the C: drive instead of the home share and it
still happened, then looking through the log with my limited interpretive
abilities, found several entries where it appears to be "searching" for
stuff - I think...you could do a much better job I'm sure.....

So it's not *really* DB corruption as much as it can't seem to find all
its parts ;)

If you need anything else.....you know where to find me!


Bill


On Wed, 13 Mar 2002, Jeremy Allison wrote:

> Hi all,
> 
> 	I discovered something today. I was given a test
> prgram by "Gerald Drouillard" <gerald at drouillard.ca> that
> allowed me to completely reproduce foxpro database corruption
> to a Samba 2.2.3a server - guarenteed.
> 
> Ths same program did not fail when run against a W2K
> server.
> 
> It was complaining about lock violations. Now Andrew's
> smbtorture lock tester does a *complete* test of 
> our locking code against W2K and we pass as identical,
> so I really doubted that we were getting the lock
> semantics wrong, especially as these were very simple
> lock requests.
> 
> One strange thing with the lock tests though - Samba 
> is *much* faster at completing the smbtorture tests than Windows
> 2000 - which made me start to wonder.
> 
> So I did some digging.......
> 
> It turns out that when a Windows client asks for a lock,
> and tells the server that the timeout is zero (ie. don't
> wait to get the lock, just check *right now* to see if
> you could get it), then a W2K server seems to do a very strange
> thing. It apparently *spins* for a short time trying to get the
> lock - it *doesn't* respond immediately ! Samba wasn't doing
> that.
> 
> And of course :-), the Foxpro database code seems to be dependent
> on this behavior.
> 
> I have just added some code to Samba (SAMBA_2_2 and HEAD)
> to force Samba to spin a parameter dependent number of times
> and also to usleep a parameter dependent time between attempts.
> Currently I have these set to 3 spins and 10usecs.
> 
> When I do this the test program passes *perfectly* against
> a SAMBA_2_2 CVS and HEAD server.
> 
> So, for people whe are experiencing MS Access and Foxpro
> database corruption problems I'd appreciate it if you
> could check this new code out and test it - I think this
> is the answer (it also fully explains why W2K is so slow
> on the lock tester as well :-) to fix the database corruption
> problems.
> 
> Let me know.....
> 
> Jeremy.
> 
>