PRB: Accessing Remote Files on Windows 95 Requires Locking

• Microsoft Win32 Application Programming Interface (API) included with: - Microsoft Windows 95

SYMPTOMS

Win32 applications on two different Windows 95 machines open a remote file for reading and writing. One writes data to the file, but the other does not see the newly-written data.

CAUSE

The Microsoft Client for Microsoft Networks and the Microsoft Client for NetWare Networks included with Windows 95 cache both reads and writes to remote files unless the files are locked. Since a Windows 95 client machine may contain cached data that has not been synchronized with the server, applications running on the client may not see the file as it actually exists on the server.

STATUS

This behavior is by design in Windows 95. The reason for this behavior is to reduce network traffic, thereby improving network performance.

MORE INFORMATION

Win32 applications that run on Windows 95 and share remote files with clients on other machines must lock the regions they read or write. When a Win32 application locks the file it is accessing, the Windows 95 network client does not cache reads or writes to the locked region. Thus, the Win32 application will see the contents of the file as it exists on the server, and will write new data directly to the file on the server.

In general, locking remote files that can be shared is good design because it prevents the file's contents from becoming corrupt when applications running on multiple machines access it simultaneously.

To lock a remote file, Win32 applications should use the LockFile API if they open the file with CreateFile or OpenFile. If an application uses a runtime library for opening the file, it should lock the file with the appropriate runtime library functions. For example, an application that uses the Microsoft Visual C++ runtime library _open() function should use the corresponding _locking() function to lock a region of the file.