[llvm] [Support] Handle delete_pending case for Windows fs::status (PR #90655)
Alexandre Ganea via llvm-commits
llvm-commits at lists.llvm.org
Tue May 14 17:37:36 PDT 2024
================
@@ -785,9 +785,20 @@ std::error_code status(const Twine &path, file_status &result, bool Follow) {
DWORD Flags = FILE_FLAG_BACKUP_SEMANTICS;
if (!Follow) {
- DWORD attr = ::GetFileAttributesW(path_utf16.begin());
- if (attr == INVALID_FILE_ATTRIBUTES)
- return getStatus(INVALID_HANDLE_VALUE, result);
+ DWORD attr;
+
+ // If getting file attributes fails due to a pending deletion, try
+ // again in a loop to avoid returning a misleading permission denied
+ // error.
+ for (int Retry = 200; Retry >= 0; --Retry) {
+ attr = ::GetFileAttributesW(path_utf16.begin());
+ if (attr != INVALID_FILE_ATTRIBUTES)
+ break;
+ std::error_code code = getStatus(INVALID_HANDLE_VALUE, result);
+ if (code != llvm::errc::delete_pending || !Retry)
+ return code;
+ ::Sleep(15);
----------------
aganea wrote:
At the risk of [repeating myself](https://github.com/llvm/llvm-project/issues/89137#issuecomment-2077056218), I feel all this is caused by the lack of synchronization between processes that write the module units (in Apple's symbol index generation). The filesystem is used as a synchronization, but since you can't provide "scopes" like a mutex guard, you end up with this issue. Is that something that was considered in the application's design @z2oh ?
https://github.com/llvm/llvm-project/pull/90655
More information about the llvm-commits
mailing list