Repository navigation
fs.rmSync cannot remove read-only files on Windows when Node is built with libc++ #64374
Description
Version
No response
Platform
Subsystem
No response
What steps will reproduce the bug?
Use fs.rmSync on a read-only file on Windows.
How often does it reproduce? Is there a required condition?
Note, this issue appears to only exhibit in Electron, but that is due to our specific build configuration (more at the bottom of this issue).
Downstream issue: electron/electron#52253
What is the expected behavior? Why is that the expected behavior?
Read-only files should be able to be removed with rmSync. This has worked previously.
What do you see instead?
As per downstream issue, the call fails with EPERM.
Additional information
Since #53617, the implementation for fs.rmSync has been written in C++ (specifically using std::filesystem::remove). However, depending on the C++ stdlib being used, this leads to divergent behavior.
- The MSVC STL, used by official Node builds, specifically includes code to support the removal of read-only files with
filesystem::remove. libc++, currently, does not have such code and uses an API that does not support the removal of read-only files.
Electron uses libc++ to build Node, so it encounters this divergent behavior. Should Node handle this inconsistency inside RmSync, or should libc++ be aligned with the behavior of the MSVC STL?
Activity
SparshGarg999 commentedon Jul 12, 2026
Hi! I've implemented a fix for this in PR #64453.
I added a Windows-specific helper
ClearReadOnlyAttributeWinsrc/node_file.ccthat is invoked if the standardstd::filesystem::removeorstd::filesystem::remove_allfails withstd::errc::operation_not_permitted(EPERM).On Windows,
libc++'s filesystem implementation does not clear theFILE_ATTRIBUTE_READONLYattribute before deleting a file (unlike MSVC's STL which does). My helper manually detects if the read-only attribute is present, clears it recursively (or for a single file/symlink), and retries the removal operation.This brings Node.js builds compiled under
libc++(such as Electron) to parity with standard MSVC STL builds.I verified the fix with a new test case in
test/parallel/test-fs-rm.jstargeting read-only file/directory removal, and confirmed that all code style (cpplint/eslint) rules pass cleanly.fs: support removing read-only files in rmSync on Windows
fs: support removing read-only files in rmSync on Windows
fs: support removing read-only files in rmSync on Windows
test: reproduce the Windows app's unerasable task folder and silent r…
fix(node): erase task folders with fs.promises.rm; refusals carry the…