| File Locking |
Article Index for File |
Website Links For File |
Information AboutFile Locking |
| CATEGORIES ABOUT FILE LOCKING | |
| computer file systems | |
|
The interceding update problem may be illustrated as in the following example: Process 'A' reads a customer Record from a file containing account information, including the customer's account balance. Process 'B' now reads the same record from the same file. Process 'A' changes the account balance and writes the new value back to the file. However, process 'B' - which still has the original values of that customer record, makes a different change to its copy of the data (for example, changes the customer's phone number) and re-writes this data to the file. Process B's copy of the data, still containing the original account balance, overwrites the changes made by process A, reverting the account balance to its previous value and causing the update of the customer balance by process 'A' to be lost. File locking prevents this problem by enforcing the Serialization of update processes to any given file. Most Operating Systems support the concept of record locking which means that individual records within any given file may be locked, so increasing the number of Concurrent update processes. FILE LOCKING IN WINDOWS Program files are automatically locked upon execution, thus preventing them from being modified or deleted while running. Programs are automatically notified if an open file is being modified by an external program. File locking in Windows is referred to as ''mandatory locking'', since locks are enforced by the operating system. The Windows locking approach can result in problems where the operating system or an application crashes without being terminated properly. This leads to a situation where access is denied to files even though they do not appear to be in use, because the operating system or a crashed application still has a lock on the file. The user will in this case have to terminate a program manually to remove the lock. This is typically done through the ''Task Manager'' utility. File locking permissions are determined by the ''sharing mode'' parameter in the LockFile function or the CreateFile function used to open files. This parameter may be either ''exclusive'', ''shared read'' and/or ''shared write''. The ReadDirectoryChangesW function can be used for notification of external changes to files opened in ''non exclusive'' mode. Locked files, also known as ''file handles'' in Windows, can be explored with the Process Explorer utility. This utility can also be used to force-close handles without needing to terminate the application holding them. Microsoft Windows XP and Server 2003 editions have introduced Volume Snapshot capability to NTFS , allowing open files to be accessed by Backup Software despite any exclusive locks. However, unless software is rewritten to specifically support this feature, the snapshot will be ''crash consistent'' only, while properly supported applications can assist the operating system in creating ''transactionally consistent'' snapshots. FILE LOCKING IN UNIX Open files and programs are not automatically locked in UNIX. There are different kinds of file locking mechanisms available in different flavours of UNIX and many operating systems support more than one kind for compatibility. The two most common mechanisms are fcntl and flock . Although some types of locks can be configured to be mandatory, file locks under UNIX are by default ''advisory''. This means that cooperating processes may use locks to coordinate access to a file between themselves, but programs are also free to ignore locks and access the file in any way they choose to. Two kinds of locks are offered: shared locks and exclusive locks. In the case of fcntl, different kinds of locks may be applied to different sections (byte ranges) of a file, or else to the whole file. Shared locks can be acquired by an unlimited number of processes at the same time, but an exclusive lock can only be acquired by one process, and cannot coexist with a shared lock. To acquire a shared lock, a process must wait until there are no processes holding any exclusive locks. To acquire an exclusive lock, a process must wait until there are no processes holding either kind of lock. Shared locks are sometimes called "read locks" and exclusive locks are sometimes called "write locks". However, because locks on UNIX are advisory, this isn't enforced. 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. This combination of inode usage and non-mandatory locking leads to great flexibility in accessing files from multiple or many processes. On the other hand, the cooperative locking approach can lead to problems when a process writes to a file without obeying file locks set by other processes. For this reason, some UNIX and UNIX-like operating systems support ''mandatory locking'' as well. Problems Both flock and fcntl have quirks which occasionally puzzle programmers from other operating systems. flock locks do not work on network filesystems such as NFS; such calls are successful noops on BSD systems and errors on Linux systems. Also, lock upgrades and downgrades release the old lock before applying the new lock. If an application downgrades an exclusive lock to a shared lock while another application is blocked waiting for an exclusive lock, the latter application will get the exclusive lock and the first application will be locked out. All fcntl locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process, even if a lock was never requested for that file descriptor. Also, fcntl locks are not inherited by a child process. The fcntl close semantics are particularly troublesome for applications which call subroutine libraries that may access files. Linux Linux 2.4 and later added notification of external changes to files with ''dnotify'' mechanism (through the ''F_NOTIFY'' parameter in fcntl). This mechanism is however being replaced by ''iNotify'' which were introduced in Linux 2.6.13. Linux also supports ''mandatory locking'' through the special "[http://www.tin.org/bin/man.cgi?section=8&topic=mount mount ''-o mand''" parameter for filesystem mounting, but this is rarely used. LOCK FILES A system similar to the use of file locking is often used by shell scripts and other programs: creation of ''lock files'', which are files whose contents are irrelevant (although often one will find the Process Identifier of the holder of the lock in the file) and whose only purpose is to signal by their presence that some resource is locked. A lock file is often the best approach if the resource to be controlled is not a regular file at all, so using methods for locking files does not apply. When using file locks, care must be taken to ensure that operations are Atomic . When creating the lock, the process must verify that it does not exist and then create it, but without allowing another process the opportunity to create it in the meantime. Various schemes are used to implement this, such as taking advantage of system calls designed for this purpose (but such system calls are not usually available to shell scripts) or by creating the lock file under a temporary name and then attempting to move it into place. |
|
|