You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Seems hard to believe, but do multiple test cases share files? #98372
I got a failure on a pull request with this error message on the Windows x64 job:
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'D:\\a\\cpython\\cpython\\build\\test_python_4912�\\test_python_worker_4268�'
I know Windows will complain if two processes try to open the same file, but should different test cases even be using the same (temporary?) files? If they are, you'd think eventually test runs on other platforms would experience problems (stomping on each others' private data, for instance).
Unfortunately, I went back only to find GitHub had elided most of the steps, including that one.
I know Windows will complain if two processes try to open the same file
It's not inherently related to processes. A filesystem manages a share-access record for each open file or directory, which tracks the number of current opens that have read, write, or delete access, as well as the number of current opens that share read, write, and delete access. The tracking is only per open file object in the kernel. Access sharing is updated and checked whenever a file or directory is opened. It has nothing inherently to do with processes, despite the misleading error message for ERROR_SHARING_VIOLATION (32). On the other hand, a file lock (i.e. a read/write lock of a byte range in a file) is associated with a process. The error code for a locking violation is ERROR_LOCKING_VIOLATION (33). A locking violation can occur even if an open has the requisite read or write access since byte-range locks are enforced at the time of access, not at the time a file is opened.
Activity
eryksun commentedon Oct 17, 2022
See issue #98219.
It's not inherently related to processes. A filesystem manages a share-access record for each open file or directory, which tracks the number of current opens that have read, write, or delete access, as well as the number of current opens that share read, write, and delete access. The tracking is only per open file object in the kernel. Access sharing is updated and checked whenever a file or directory is opened. It has nothing inherently to do with processes, despite the misleading error message for
ERROR_SHARING_VIOLATION(32). On the other hand, a file lock (i.e. a read/write lock of a byte range in a file) is associated with a process. The error code for a locking violation isERROR_LOCKING_VIOLATION(33). A locking violation can occur even if an open has the requisite read or write access since byte-range locks are enforced at the time of access, not at the time a file is opened.arhadthedev commentedon Oct 18, 2022
The bug is currently investigated and fixed for Windows 11 in gh-97641. It looks like the fix will remedy the GitHub Actions too.
erlend-aasland commentedon Oct 18, 2022
Which fix? Is there a PR?
erlend-aasland commentedon Jan 15, 2024
Is there an actionable item here? This issue has been stale since Oct 2022; suggesting to close it.
smontanaro commentedon Jan 15, 2024
Wouldn't appear so. Close it...