How Windows 95 Handled Network File Locking

Windows 95 managed file locking across local area networks (LANs) through a coordinated architecture of 32-bit virtual device drivers, the Server Message Block (SMB) protocol, and support for opportunistic locking (oplocks). By translating local file system calls into standardized network requests, Windows 95 allowed multiple users to safely access, share, and modify files across peer-to-peer and client-server environments without corrupting data.

The Network Redirector and IFS Manager

At the core of Windows 95 file management was the Installable File System (IFS) Manager (IFSMGR.VXD). When an application attempted to open, read, write, or lock a file, the IFS Manager determined whether the target resided locally or on a remote share.

For remote resources across a Windows-based network, the IFS Manager passed the request to the Microsoft Network Redirector (VREDIR.VXD). If the client connected to a Novell NetWare network instead, the request routed through NetWare Redirector (NWREDIR.VXD). These redirectors acted as the translation bridge, converting local file I/O operations into network-compatible protocol packets.

Share Modes and Byte-Range Locking

Windows 95 enforced two primary types of network file locks through the SMB protocol:

  1. Share Access Modes (Open Modes): When opening a file over the LAN, an application specified its intended access (read, write, or read/write) and its share mode (Deny Read, Deny Write, Deny None, or Exclusive). The remote server evaluated these flags against existing handles to the file. If an incoming request conflicted with an active open mode, the network server rejected the operation, returning an access-denied error.

  2. Byte-Range Locking: To support multi-user applications like database systems (such as Microsoft Access or FoxPro), Windows 95 supported granular record locking. Instead of locking an entire file, applications used byte-range locks to isolate specific offsets within a file. The client issued SMB_COM_LOCKING_ANDX commands to the host server. The host tracked these offsets in memory, preventing concurrent clients from overwriting records currently being edited, while still allowing simultaneous reads or edits to other parts of the same file.

Opportunistic Locking (Oplocks)

Network latency over early LAN hardware introduced performance bottlenecks when repeatedly requesting locks for remote files. Windows 95 utilized Opportunistic Locks (Oplocks) when communicating with SMB servers (such as Windows NT Server or other Windows 95 machines hosting shares via VSERVER.VXD).

Oplocks allowed a client to temporarily assume that no other machine was accessing a file, permitting the client to cache read data, write data, and lock states locally without immediately notifying the server. Windows 95 supported multiple oplock states:

  • Level 1 (Exclusive) Oplocks: Granted when only one client had the file open. The client could cache reads and writes locally without making round-trip network calls for every single byte-range lock.
  • Oplock Breaks: If a second client requested access to the same file, the server sent an "oplock break" notification to the first client. The first client flushed its cached writes, released its exclusive lock, and downgraded to standard non-cached locking or a Level 2 (read-only) oplock.
  • Batch Oplocks: Used primarily for batch files (.BAT), where the client kept the file open across multiple command executions to prevent repeatedly opening and locking the file across the network.

Peer-to-Peer vs. Dedicated Servers

Because Windows 95 supported peer-to-peer networking, any Windows 95 workstation could function as a file server using the File and Printer Sharing service (VSERVER.VXD). When acting as a host, VSERVER.VXD maintained the lock arbitration table for connected peers. While functional for small workgroups, peer-hosted locking lacked the robust scalability and error-recovery mechanisms of Windows NT Server, occasionally leaving orphaned locks if a peer disconnected abruptly without sending an unlock or close packet.