Skip to content

fix(backup): retry fs.rm on EBUSY to prevent retry-loop collapse on Windows#101395

Closed
tzy-17 wants to merge 1 commit into
openclaw:mainfrom
tzy-17:fix/101382-backup-ebusy-retry
Closed

fix(backup): retry fs.rm on EBUSY to prevent retry-loop collapse on Windows#101395
tzy-17 wants to merge 1 commit into
openclaw:mainfrom
tzy-17:fix/101382-backup-ebusy-retry

Conversation

@tzy-17

@tzy-17 tzy-17 commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

What Problem This Solves

Fixes #101382: On Windows, fs.rm can throw EBUSY when the tar process leaked a file descriptor. The catch block logged a warning and continued, but the temp file remained locked — causing the next runTar attempt to fail immediately because it couldn't overwrite the locked file. This completely defeated the BACKUP_TAR_BACKOFF_MS retry mechanism.

Why This Change Was Made

Added a short retry loop (3 attempts, 100ms/200ms backoff) for EBUSY before falling through to the existing warning path. This gives the OS time to release the file lock, allowing the retry loop to function correctly.

User Impact

  • Backup creation on Windows survives transient file descriptor leaks from the tar process
  • The retry backoff mechanism now works correctly instead of being bypassed

Evidence

  • pnpm test src/infra/backup-create.test.ts — 39 tests pass
  • oxlint passes

🤖 Generated with Claude Code

…indows

fs.rm can throw EBUSY on Windows when the tar process leaked a
file descriptor. The existing catch logged a warning and continued,
but the temp file remained locked, causing the next runTar attempt
to fail immediately — defeating the BACKUP_TAR_BACKOFF_MS retry.

Add a short retry loop (3 attempts with 100ms/200ms backoff) for
EBUSY before falling through to the existing warning path.

Fixes openclaw#101382
@vincentkoc vincentkoc self-assigned this Jul 7, 2026
@vincentkoc

Copy link
Copy Markdown
Member

Closing as the weaker duplicate of #101397 for #101382.

Both branches add short EBUSY retries around the same best-effort temp-archive cleanup. #101397 is the better-documented discussion candidate, but neither branch currently proves the claimed Windows failure chain, adds a regression test, or addresses the stronger design of using an independent temp path per tar attempt.

This closure consolidates the issue; it is not a merge endorsement of #101397.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: fs.rm EBUSY swallow in backup-create.ts defeats retry backoff loop on Windows

2 participants