Hi John K. Hohm,
On Friday 21 March 2003 12:15 pm, John K. Hohm wrote:
This resolution will make a ton of business apps based on desktop database software that much closer to working.
I'm not so sure. I expect most database software depends on the mandatory nature of LockFile(), i.e. that a ReadFile() or WriteFile() from another process on a locked region fails with ERROR_LOCK_VIOLATION.
Yep, you seem to be correct.
Typically, one process will LockFile() an area, then update on-disk structures in such a way that another process reading during the update would get confused were it not for ReadFile() refusing to read the locked bytes. Note that the reading process does not LockFile() to read, it just tries ReadFile() and handles its failure (typically by waiting and trying again later).
For database software that uses read/write locks via LockFileEx(), the standard Unix advisory lock semantics are just fine, and those patches are indeed the ticket. However, advisory locking is generally more difficult to manage, and LockFileEx() is not supported on Windows 95/98/Me, so I doubt many apps use it.
I just confirmed... while locking seems to work if two instances of Visual Foxpro are running on Wine on the same machine, it DOES NOT work over the network. I had one instance on Wine and one instance on WinNT. Both instances were interacting with the same table on a third machine. The two instances of Visual FoxPro did not respect each other's locks. Bummer. Big bummer.
From what I can tell, mandatory locking on Linux involves tricks like using a special mount option, and setting the SGID bit of the file to be locked before the locking process starts; I'm not sure which other Unixen even support it.
So... chances of this ever getting implemented on Wine are, in your opinion, pretty slim? If so that's too bad, because I saw a great possibility of porting lots of legacy business apps over to Linux using Wine. There are, as I said before, a ton of apps out there built on desktop database software... bummer.