cadrumo.core.windows_contention module¶
The Windows error codes a peer’s open handle produces, declared once.
Windows refuses to remove or replace a file while another process holds a
handle to it. Two codes carry that refusal, and CPython surfaces both as
PermissionError: ERROR_SHARING_VIOLATION (32) while a peer holds
the file open, and ERROR_ACCESS_DENIED (5) once a delete against it is
already pending. Both clear when the last handle closes.
Windows does not distinguish either from a denying ACL or a read-only attribute at the operation boundary, so the code alone never proves contention – a retry budget is what separates them: a transient block clears inside the window, and a permanent one outlasts it. Each caller owns that budget, because the right answer depends on what losing the race costs it.
Declared here rather than in either consumer because the two that need it
cannot share a module: core.lockfile_unlink imports
core.logging, and core.bucket_pointer is read during
Settings() bootstrap and must not (its own comments record the circular
bootstrap that import recreates). This module imports nothing, so it is safe
from both.
Nothing is absorbed off Windows: winerror is absent there, so
is_windows_contention() is False for every POSIX EACCES, which is
genuine and must propagate.
- WINDOWS_CONTENDED_ACCESS_ERRORS¶
ERROR_ACCESS_DENIEDandERROR_SHARING_VIOLATION.