The following example illustrates the interceding update problem: Most operating systems support the concept of record locking, which means that individual records within any given file may be locked, thereby increasing the number of concurrent update processes.
IBM pioneered file locking in 1963 for use in mainframe computers using OS/360, where it was termed "exclusive control".
The client will observe slower access because read and write operations must be sent to the server where the file is stored.
The sharing mode (dwShareMode) parameter of the CreateFile[2] function (used to open files) determines file-sharing.
The Windows API function LockFile[5] can also be used and acquires an exclusive lock on the region of the file.
Any attempt to do so will be denied with a sharing violation error, despite the fact that the program file is not opened by any application.
[citation needed] Microsoft Windows XP and Server 2003 editions have introduced volume snapshot (VSS) capability to NTFS, allowing open files to be accessed by backup software despite any exclusive locks.
Unix-like operating systems (including Linux and Apple's macOS) do not normally automatically lock open files.
Thus it is possible for a database to have a concept of "shared writes" vs. "exclusive writes"; for example, changing a field in place may be permitted under shared access, whereas garbage-collecting and rewriting the database may require exclusive access.
Together with non-mandatory locking, this leads to great flexibility in accessing files from multiple processes.
For this reason, some Unix-like operating systems also offer limited support for mandatory locking.
It is not part of POSIX, however, and BSD-derived operating systems such as FreeBSD, OpenBSD, NetBSD, and Apple's macOS do not support it.
Some Unix-like operating systems prevent attempts to open the executable file of a running program for writing; this is a third form of locking, separate from those provided by fcntl and flock.
This simplifies coding for network servers and helps prevent race conditions, but can be confusing to the unaware.
Kernel 2.6.12 and above implement flock calls on NFS files using POSIX byte-range locks.
The fcntl close semantics are particularly troublesome for applications that call subroutine libraries that may access files.
Preservation of the lock status on open file descriptors passed to another process using a Unix domain socket is implementation dependent.
The problem is another user attached to the same file has their own local buffers, and the same thing is happening for them.
The best solution to this problem is to use unbuffered I/O (read and write) with flock, which also means using lseek instead of fseek and ftell.
For example, a lock file might govern access to a set of related resources, such as several different files, directories, a group of disk partitions, or selected access to higher level protocols like servers or database connections.
On some Unix-like systems, utilities such as fstat and lockf can be used to inspect the state of file locks by process, by filename, or both.
[citation needed] On Windows systems, if a file is locked, it's possible to schedule its moving or deletion to be performed on the next reboot.