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.
Ok:
http://www.paulmcnett.com/vfp/wine/lt1.gz
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.