Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
File locking
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== 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 delete<ref name="createfile-parameters">{{cite web |url=https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createfilew#parameters |title=<code>CreateFileW</code> function |series=windows-sdk-content |department=Windows Software Development Toolkit |publisher=Microsoft Corporation |website=Microsoft Docs |access-date=2018-11-07}}</ref> # using byte-range locks to arbitrate read and write access to regions within a single file<ref>{{cite web |url=https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-lockfileex |title=<code>LockFileEx</code> function |series=windows-sdk-content |department=Windows Software Development Toolkit |publisher=Microsoft Corporation |website=Microsoft Docs |access-date=2018-11-07}}</ref> # by Windows file systems disallowing executing files from being opened for write or delete access Windows inherits the semantics of share-access controls from the [[MS-DOS]] system, where sharing was introduced in MS-DOS 3.3 . Thus, an application must explicitly allow sharing when it opens a file; otherwise it has exclusive read, write, and delete access to the file until closed (other types of access, such as those to retrieve the attributes of a file are allowed.) For a file opened with shared access, applications may then use byte-range locking to control access to specific regions of the file. Such byte-range locks specify a region of the file (offset and length) and the type of lock (shared or exclusive). Note that the region of the file being locked is ''not'' required to have data within the file, and applications sometimes exploit this ability to implement their functionality. For applications that use the file read/write [[API]]s in Windows, byte-range locks are enforced (also referred to as ''mandatory locks'') by the file systems that execute within Windows. For applications that use the file mapping [[API]]s in Windows, byte-range locks are not enforced (also referred to as ''advisory locks.'') Byte-range locking may also have other side-effects on the Windows system. For example, the Windows file-sharing mechanism will typically disable client side caching of a file for ''all'' clients when byte-range locks are used by ''any'' client. The client will observe slower access because read and write operations must be sent to the server where the file is stored. Improper error-handling in an application program can lead to a scenario where a file is locked (either using "share" access or with byte-range file locking) and cannot be accessed by other applications. If so, the user may be able to restore file access by manually terminating the malfunctioning program. This is typically done through the [[Windows Task Manager|Task Manager]] utility. The ''sharing mode'' (dwShareMode) parameter of the <code>CreateFile</code><ref name="createfile-parameters"/> function (used to open files) determines file-sharing. The sharing mode can be specified to allow sharing the file for read, write, or delete access, or any combination of these. Subsequent attempts to open the file must be compatible with all previously granted sharing-access to the file. When the file is closed, sharing-access restrictions are adjusted to remove the restrictions imposed by that specific file open. Byte-range locking type is determined by the ''<code>dwFlags</code>'' parameter in the <code>LockFileEx</code><ref>{{cite web |url=https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfileex#parameters |title=<code>LockFileEx</code> function |series=windows-sdk-content |department=Windows Software Development Toolkit |publisher=Microsoft Corporation |website=Microsoft Docs |access-date=2020-07-05}}</ref> function used to lock a region of a file. The [[Windows API]] function <code>LockFile</code><ref> {{cite web |url=https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfile |title=<code>LockFile</code> function |series=windows-sdk-content |department=Windows Software Development Toolkit |publisher=Microsoft Corporation |website=Microsoft Docs |access-date=2020-07-05}}</ref> can also be used and acquires an exclusive lock on the region of the file. Any file containing an executable program file that is currently running on the computer system as a program (e.g. an <code>[[EXE]]</code>, [[COM file|<code>COM</code>]], [[Dynamic-link library|<code>DLL</code>]], [[List of Control Panel applets (Windows)|<code>CPL</code>]] or other binary program file format) is normally locked by the operating system itself, preventing any application from modifying or deleting it. 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. However, some access is still allowed. For example, a running application file can be renamed or copied (read) even when executing. Files are accessed by applications in Windows by using ''[[File descriptor|file handles]]''. These file handles 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. This can cause an undefined behavior, since the program will receive an unexpected error when using the force-closed handle and may even operate on an unexpected file since the handle number may be recycled.{{citation needed|date=November 2017}} [[Microsoft Windows XP]] and [[Windows Server 2003|Server 2003]] editions have introduced [[Volume Shadow Copy Service|volume snapshot]] (<code>VSS</code>) 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. Other commercial software for accessing locked files under Windows include [[File Access Manager]] and [[Open File Manager]]. These work by installing their own [[Device driver|drivers]] to access the files in [[kernel mode]].
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)