An important detail is that Oplocks are invoked by the file system, not an application API. Therefore, an application can close an oplocked file, but the file system does not relinquish the Oplock. When the Oplock break is issued, the file system then simply closes the file in preparation for the subsequent open by the second process.
4.2UNIX
UNIX utilizes 2 kinds of file locking:
Advisory locking
Mandatory locking
Both lock types are implemented with the same function calls: fcntl and lockf. fcntl is the POSIX interface (introduced at SVR4), and lockf is provided for backward compatibility. The calling semantics are slightly different, but the functionality is basically the same.
Both functions specify read and/or write locking, and allow for
ADVISORY LOCKING assumes that all processes attempting to access a file participate in the locking protocol by calling the locking functions correctly and honoring the lock status of the file. There is no requirement that a process must adhere to the advisory locking protocol. A process that does not participate in the protocol can obliviously write or read to a file that is locked with locking functions. Therefore there is a significant assumption of risk of data corruption with advisory locking.
MANDATORY LOCKING is implemented with function calls identical to advisory locking. Mandatory locking is then enabled
Note that UNIX does not employ the concept of Mandatory Share Mode (Open Mode) locking like Windows does. UNIX locking consists of byte range locking and is strictly programmatic on a previously opened file. Also, UNIX is incapable of sending an oplock break to a client, and therefore cannot interoperate with Windows clients using Opportunistic Locking.
4.3NFS
File locking for NFS is provided by two cooperating protocols:
Network Lock Manager
Network Status Monitor
10