| Previous | Next |
| STATUS_EA_CORRUPT_ERROR | STATUS_LOCK_NOT_GRANTED |
STATUS_FILE_LOCK_CONFLICT
STATUS_FILE_LOCK_CONFLICT means that the handle may be valid and the file may have been opened successfully, but the requested read or write touches a byte range that another lock currently protects. It is therefore distinct from a sharing violation, which is decided while opening the handle.
What Windows file locks protect
Windows supports byte-range locks rather than only whole-file locks. With LockFileEx, an exclusive lock prevents other processes from reading or writing the locked range; a shared lock prevents writes to that range. The rest of the file can remain accessible. A conflict can therefore appear only for particular offsets and lengths.
Practical checks
- Log the requested offset and length together with the I/O operation that returned the status.
- Verify that all participants use the same lock granularity and that they unlock ranges on every completion and error path.
- Do not assume that a process can access a range through a second handle merely because it owns another handle to the same file.
- For asynchronous code, decide whether the operation should wait, fail fast, or retry with backoff; do not silently write around a lock.
On SMB servers, both STATUS_FILE_LOCK_CONFLICT and STATUS_LOCK_NOT_GRANTED can be reported for incompatible byte-range locking operations. The latter is normally associated with the attempt to obtain a lock, while this status commonly appears when an I/O request conflicts with an existing lock.
See LockFileEx, Locking and Unlocking Byte Ranges in Files, and the NTSTATUS reference.
Looking for a different code? Search another status or error code.