LockFile() and UnlockFile() are working

[John K. Hohm]

> 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.  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.