mirror of
https://github.com/CloakHQ/CloakBrowser.git
synced 2026-10-18 23:07:13 -05:00
ShubhamandCloakHQ
9fb05e0fc8
* fix(download): make concurrent first-run downloads safe _extract_archive deleted the install dir and then extracted into it in place. When several processes or threads start on an empty cache, a second caller can delete the first caller's install mid-extraction, or pass the "binary exists and is executable" check on a binary that is still being written. On Linux that surfaces as ETXTBSY on spawn; on macOS as dlopen failures and "Directory not empty", and the cache can be left permanently incomplete. Extract into a uniquely named sibling staging dir and rename it into place. If the destination already holds a complete install, another caller won and the staged copy is discarded; an incomplete leftover is still replaced as before. * fix(js): make concurrent first-run downloads safe Same race as the Python wrapper: extractArchive deleted the install dir and extracted into it in place, so concurrent ensureBinary() calls on an empty cache could delete each other's install or return a binary that was still being written (spawn ETXTBSY on Linux). Extract into a uniquely named sibling staging dir and rename it into place, keeping an existing complete install if another caller won. Also name the temporary archive with randomUUID() instead of Date.now(), which collided for calls made in the same millisecond. * fix(dotnet): make concurrent first-run downloads safe Same race as the Python and JS wrappers: ExtractArchive deleted the install dir and extracted into it in place, so concurrent EnsureBinaryAsync() calls on an empty cache failed with "already exists" / DirectoryNotFoundException or saw a half-written install. Extract into a uniquely named sibling staging dir and move it into place, keeping an existing complete install if another caller won. * fix(download): replace a partial install safely under concurrent callers When an incomplete install dir was left over from an interrupted run, every concurrent caller saw it as incomplete and deleted it in place. The first to finish renamed its staging dir into place; the others' unguarded second rename then failed (ENOTEMPTY, FileNotFoundError, DirectoryNotFoundException), and a late delete could remove files from an install another caller had just moved in. With 8 concurrent callers, 7 raised in each round. Rename the leftover aside to a unique <install>.stale-<id> dir and delete it from there, then retry the staging rename a bounded number of times, keeping a complete install if another caller got there first. Applies to the Python, JS and .NET clients, each with a regression test that starts several concurrent callers on a partial install. The JS test uses separate processes, since callers in one process cannot interleave inside the synchronous rename block. * fix(download): retry directory renames Windows transiently denies Antivirus and indexers on Windows briefly hold freshly extracted files open, which fails the directory rename with access denied. Retry that rename for about 2.5 seconds while the destination does not exist, in all three clients. Cleanup of the staging and stale dirs is now best effort so a failed delete never masks the error being raised. --------- Co-authored-by: CloakHQ <cloakhq@pm.me>