| Previous | Next |
| ERROR_EXE_CANNOT_MODIFY_STRONG_SIGNED_BINARY | ERROR_CHECKOUT_REQUIRED |
ERROR_FILE_CHECKED_OUT
Another user or workflow owns the current edit lock
ERROR_FILE_CHECKED_OUT is a Win32 result associated with document-management and collaborative storage systems. When ERROR_FILE_CHECKED_OUT is returned, diagnosis should begin with the exact API, target object, and operation that produced it rather than with the message text alone.
What the result means
The file is checked out or locked for editing by another user. For ERROR_FILE_CHECKED_OUT, the practical meaning depends on the caller and on whether the affected object is local, remote, removable, policy-managed, or handled asynchronously. Diagnostics for ERROR_FILE_CHECKED_OUT should retain its symbolic name, numeric value, and the operation name together.
What to check
- Identify the user or session holding the checkout.
- Check whether the lock is active or stale after a crashed client.
- Avoid overwriting the server copy with a local version while ownership is unresolved.
- Use the repository or document system checkout API rather than filesystem-only checks.
Recommended handling
Prompt the user to wait, request ownership transfer, or create a separate copy. Administrative lock removal should be audited because it can discard another editor’s pending work.
Developer notes
Code handling ERROR_FILE_CHECKED_OUT should capture the failing API, resolved path or device identity, requested access, process identity, and the first observed error. After a call that reports ERROR_FILE_CHECKED_OUT, read GetLastError() immediately because later cleanup or logging can overwrite the value. Retry ERROR_FILE_CHECKED_OUT only when the specific condition is documented as transient, using a bounded delay and cancellation support.
References
- Microsoft: System error codes relevant to ERROR_FILE_CHECKED_OUT
- Microsoft: File management context for ERROR_FILE_CHECKED_OUT
Looking for a different code? Search another status or error code.