Under the hood
Useful1 Signal1
Rename retries treat an existing destination as fatal only if it is unwritable, but the path is unreachable.
The relaxed rename check exists but the retry loop never reaches it.
What's wrong with this entry?
Anonymous. No account, no email.
What
The file-rename helpers used to stop retrying whenever the destination file already existed; they now stop only when it exists and is not writable by its owner. The retry loop that decides whether to reach this check always answers no, so nothing changes in practice.
Details
- Applies to both the async and synchronous rename paths; the synchronous loop previously lacked the check entirely.
- The existence test switched to one that does not follow symlinks and tests the owner-write permission bit.
Evidence
renameSync
Strings lifted out of the shipped bundle, so the claim above can be checked against them.