LockFile() and UnlockFile() are working

Paul McNett p at ulmcnett.com
Sat Mar 22 14:15:39 CST 2003

On Friday 21 March 2003 09:21 pm, Alexandre Julliard wrote:

> It's quite possible that there are still bugs in the implementation.
> One thing to test would be with two clients running on the same
> machine, so that they use the same wineserver; this way all locking
> will be done internally without using Unix locks, and this might help
> identifying where the problem is.

Ok, I just did my simple RLOCK() testing using 2 wineservers on one local 
machine.  The locking mechanism seemed to work perfectly using Unix locks. 
Both instances of Visual FoxPro respected one another's record locks. So it 
works locally... good!  Presumably, this also would mean that the locks 
would be respected over NFS, although I have yet to test this.

However, hosting the database on Linux, accessed by Linux/Wine directly at 
/tmp/db.dbf and by Windows over samba, the behavior is not correct.  It 
seems that instead of a range lock, a complete file lock is propogated, and 
it also seems that this file lock is never released.

> Also if you can reproduce the bug easily I'd be very interested to see
> a +file,+server trace.



This shows the trace from the point of creating the dbf file (CREATE TABLE 
t:/locktest2 (cchar c(32))), closing it, reopening it, locking a record, 
and closing the app.  Once the record was locked on the Linux side, my 
Windows instance of VFP couldn't write anywhere in the table.  Once the 
record was unlocked on the Linux side, the Windows instance still couldn't 
write anywhere in the table.  Basically, once locked, the windows side 
thought the entire file was read-only when in actuality only the one record 
should have been locked.

Paul McNett - p at ulmcnett.com
Hollister, California, USA

More information about the wine-devel mailing list