GetWiki
file locking
ARTICLE SUBJECTS
being →
database →
ethics →
fiction →
history →
internet →
language →
linux →
logic →
method →
news →
policy →
purpose →
religion →
science →
software →
truth →
unix →
wiki →
ARTICLE TYPES
essay →
feed →
help →
system →
wiki →
ARTICLE ORIGINS
critical →
forked →
imported →
original →
file locking
please note:
- the content below is remote from Wikipedia
- it has been imported raw for GetWiki
{{Short description|Computer mechanism}}{{More citations needed|date=February 2015}}File locking is a mechanism that restricts access to a computer file, or to a region of a file, by allowing only one user or process to modify or delete it at a specific time and to prevent reading of the file while it's being modified or deleted.Systems implement locking to prevent the classic interceding update scenario, which is a typical example of a race condition, by enforcing the serialization of update processes to any given file. The following example illustrates the interceding update problem: - the content below is remote from Wikipedia
- it has been imported raw for GetWiki
- Process A reads a customer record from a file containing account information, including the customer's account balance and phone number.
- Process B now reads the same record from the same file, so it has its own copy.
- Process A changes the account balance in its copy of the customer record and writes the record back to the file.
- Process B, which still has the original stale value for the account balance in its copy of the customer record, updates the account balance and writes the customer record back to the file.
- Process B has now written its stale account-balance value to the file, causing the changes made by process A to be lost.
In mainframes
IBM pioneered file locking in 1963 for use in mainframe computers using OS/360, where it was termed "exclusive control".BOOK,weblink 162â164, IBM System/360 Operating System: Job Control Language Reference, June 1971, IBM, GC28-6704-1,In Microsoft Windows
Microsoft Windows uses three distinct mechanisms to manage access to shared files:- using share-access controls that allow applications to specify whole-file access-sharing for read, write, or deleteWEB,weblink CreateFileW function, windows-sdk-content, Windows Software Development Toolkit, Microsoft Corporation, Microsoft Docs, 2018-11-07,
- using byte-range locks to arbitrate read and write access to regions within a single fileWEB,weblink LockFileEx function, windows-sdk-content, Windows Software Development Toolkit, Microsoft Corporation, Microsoft Docs, 2018-11-07,
- by Windows file systems disallowing executing files from being opened for write or delete access
In Unix-like systems
Unix-like operating systems (including Linux and Apple's macOS) do not normally automatically lock open files. Several kinds of file-locking mechanisms are available in different flavors of Unix, and many operating systems support more than one kind for compatibility. The most common mechanism is {{man|sh|fcntl|SUS||inline}}. Two other such mechanisms are {{man|2|flock|FreeBSD||inline}} and {{man|3|lockf|FreeBSD||inline}}, each of which may be implemented atop fcntl or may be implemented separately from fcntl. 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 among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O.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 held by multiple processes at the same time, but an exclusive lock can only be held by one process, and cannot coexist with a shared lock. To acquire a shared lock, a process must wait until no processes hold any exclusive locks. To acquire an exclusive lock, a process must wait until no processes hold either kind of lock. Unlike locks created by fcntl, those created by flock are preserved across forks, making them useful in forking servers. It is therefore possible for more than one process to hold an exclusive lock on the same file, provided these processes share a filial relationship and the exclusive lock was initially created in a single process before being duplicated across a fork.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.File locks apply to the actual file, rather than the file name. This is important since Unix allows multiple names to refer to the same file. Together with non-mandatory locking, this leads to great flexibility in accessing files from multiple 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-like operating systems also offer limited support for mandatory locking.WEB, Mandatory File Locking for the Linux Operating System, Documentation / File Systems, kernel.org,weblink 2011-10-08, On such systems, a file whose setgid bit is on but whose group execution bit is off when that file is opened will be subject to automatic mandatory locking if the underlying filesystem supports it. However, non-local NFS partitions tend to disregard this bit.WEB, Use Setuid, Setgid, and Sticky Bits with Server for NFS,weblink cc731734(WS.10)Solaris (operating system)>Solaris, HP-UX, and Linux operating systems. 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.VIEGA, JOHN >EDITION=1ST | YEAR=2003 | PUBLISHER=O'REILLY MEDIA | ISBN=978-0-596-00394-4 | PAGE=792 | QUOTE=SUPPORT FOR MANDATORY LOCKS VARIES GREATLY FROM ONE UNIX VARIANT TO ANOTHER. BOTH LINUX AND SOLARIS SUPPORT MANDATORY LOCKS, BUT DARWIN (OPERATING SYSTEM) | , FREEBSD, NETBSD, AND OPENBSD DO NOT, EVEN THOUGH THEY EXPORT THE INTERFACE USED BY LINUX AND SOLARIS TO SUPPORT THEM. ON SUCH SYSTEMS, THIS INTERFACE CREATES ADVISORY LOCKS. SUPPORT FOR MANDATORY LOCKING DOES NOT EXTEND TO NFS., Linux also supports mandatory locking through the special -o mand parameter for file system mounting ({{man>8 | Linux | inline}}), but this is rarely used.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.{{Anchor|POSIX}}ProblemsMore than one process can hold an exclusive flock on a given file if the exclusive lock was duplicated across a later fork. This simplifies coding for network servers and helps prevent race conditions, but can be confusing to the unaware.Mandatory locks have no effect on the unlink system call. Consequently, certain programs may, effectively, circumvent mandatory locking. Stevens & Rago (2005) observed that the ed editor indeed did that.BOOK, W. Richard, Stevens, Stephen A., Rago, 27 June 2005, Advanced Programming in the UNIX Environment, Addison-Wesley Professional, Second, 978-0201433074, 456, Whether and how flock locks work on network filesystems, such as NFS, is implementation dependent. On BSD systems, flock calls on a file descriptor open to a file on an NFS-mounted partition are successful no-ops. On Linux prior to 2.6.12, flock calls on NFS files would act only locally. Kernel 2.6.12 and above implement flock calls on NFS files using POSIX byte-range locks. These locks will be visible to other NFS clients that implement fcntl-style POSIX locks, but invisible to those that do not.WEB,weblink Linux NFS FAQ: D, Commonly occurring error messages, nfs.sourceforge.net, Source Forge, 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 may get the exclusive lock and lock the first application out. This means that lock downgrades can block, which may be counter-intuitive.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 that call subroutine libraries that may access files. Neither of these "bugs" occurs using real flock-style locks.Preservation of the lock status on open file descriptors passed to another process using a Unix domain socket is implementation dependent.Buffered I/O problemsOne source of lock failure occurs when buffered I/O has buffers assigned in the user's local workspace, rather than in an operating system buffer pool. fread and fwrite are commonly used to do buffered I/O, and once a section of a file is read, another attempt to read that same section will, most likely, obtain the data from the local buffer. The problem is another user attached to the same file has their own local buffers, and the same thing is happening for them. An fwrite of data obtained from the buffer by fread will not be obtaining the data from the file itself, and some other user could have changed it. Both could use flock to ensure exclusive access, which prevents simultaneous writes, but since the reads are reading from the buffer and not the file itself, any data changed by user #1 can be lost by user #2 (over-written). 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. Of course, you'll have to make adjustments for function parameters and results returned. Generally speaking, buffered I/O is unsafe when used with shared files.In AmigaOSIn AmigaOS, a lock on a file (or directory) can be acquired using the Lock function (in the dos.library). A lock can be shared (other processes can read the file/directory, but can't modify or delete it), or exclusive so that only the process which successfully acquires the lock can access or modify the object. The lock is on the whole object and not part of it. The lock must be released with the UnLock function: unlike in Unix, the operating system does not implicitly unlock the object when the process terminates.Lock filesShell scripts and other programs often use a strategy similar to the use of file locking: 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 sole 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. 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.When using lock files, care must be taken to ensure that operations are atomic. To obtain a lock, the process must verify that the lock file does not exist and then create it, whilst preventing another process from creating it in the meantime. Various methods to do this include:
Unlocker softwareAn unlocker is a utility used to determine what process is locking a file, and displays a list of processes as well as choices on what to do with the process (kill task, unlock, etc.) along with a list of file options such as delete or rename. Their purpose is to remove improper or stale file locks, which often arise from anomalous situations, such as crashed or hung processes, that lead to file locks that persist despite the owning process having died already. 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|date=December 2014}}On Windows systems, if a file is locked, it's possible to schedule its moving or deletion to be performed on the next reboot. This approach is typically used by installers to replace locked system files.Version control systemsIn version control systems file locking is used to prevent two users changing the same file version in parallel and then when saving, the second user to overwrite what first user changed. This is implemented by marking locked files as read-only in the file system. A user wanting to change the file performs an unlock (also called checkout) operation, and until a check-in (store) operation is done, or the lock is reverted, nobody else is allowed to unlock the file.See alsoReferences{{Reflist|30em}}External links
|
- content above as imported from Wikipedia
- "file locking" does not exist on GetWiki (yet)
- time: 2:48pm EDT - Thu, Apr 25 2024
- "file locking" does not exist on GetWiki (yet)
- time: 2:48pm EDT - Thu, Apr 25 2024
[ this remote article is provided by Wikipedia ]
LATEST EDITS [ see all ]
GETWIKI 23 MAY 2022
The Illusion of Choice
Culture
Culture
GETWIKI 09 JUL 2019
Eastern Philosophy
History of Philosophy
History of Philosophy
GETWIKI 09 MAY 2016
GetMeta:About
GetWiki
GetWiki
GETWIKI 18 OCT 2015
M.R.M. Parrott
Biographies
Biographies
GETWIKI 20 AUG 2014
GetMeta:News
GetWiki
GetWiki
© 2024 M.R.M. PARROTT | ALL RIGHTS RESERVED