Locking problems in 2.2.2

[Jeremy Allison]

On Sun, Dec 02, 2001 at 04:01:58PM +0100, Hannes Schmidt wrote:
> Hi, 
> 
> I am using a small network of, say, 10 W2K workstations on which I run a 
> database application using shared table and index files on a Samba 2.2.2 server 
> (Suse Linux 7.2). The application was just ported from Clipper to XBase++. The 
> Clipper compiled app (it's a 16-bit DOS application) runs fine. The 32-bit XBase++ 
> app produces corrupt index files and behaves eratically after several minutes 
> under normal workload. Of course I was blaming the XBase++ compiler first. I 
> then tried playing around with the locking settings in smb.conf, trying to set 
> Samba to what I thought would be the least aggressive configuration (oplock OFF, 
> blocking locks OFF, strict locking ON and so on). Besides Samba beeing slower it 
> didn't effect he problem in any way.
> 
> I made the following observations:
> 
> a)  At times, using the XBase compiled app, the index files would get huge. 
>     Their size would be around 2 Gigs. The lock offset for index files is 2 Gigs 
>     plus the record offset.
> 
> b)  I have a little utility program which I use for managing the database. This 
>     program is a Clipper-compiled 16-bit DOS app. Usually, I cannot use that 
>     utility when the main application is using the files. This is because the 
>     utility opens the file in exclusive mode. To my surprise I *was* able to 
>     open the database in the 16-bit utility even while the 32-bit XBase++ 
>     compiled main app was using it!
>     
> c)  In my desparation I moved all the files to a spare W2K server and the 
>     problems went away! I didn't have time to try previous versions of Samba.
> 
> d)  I have seen more messages in this list reporting 2.2.2 problems regarding 
>     corrupted index files and record locks.
>     
> What should I try next? I would really like to continue using Samba as my main 
> file server. BTW: both, the W2K server and the workstations are service pack 2.

This is due to the differences between set allocation, and
set end of file, which were not properly separated in Samba 2.2.2.

I think we've fixed this (along with many other bugs) in the
current SAMBA_2_2 CVS tree. If you'd test this for us to see
that the latest code fixes your problems and report back I'd
appreciate it, as it will ensure the 2.2.3 release containes
fixes for your problem.

Thanks,

	Jeremy.