fs: cpSync copyDir fast path can terminate on filesystem errors
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 122k
- Forks
- 37.3k
- Avg merge
- 4d 2h
- Merged PRs (30d)
- 283
Description
Version
v22.17.0 and later; verified against v27.0.0-pre built from current main.
Platform
Microsoft Windows NT 10.0.26100.0 x64
Subsystem
fs
What steps will reproduce the bug?
Run this script on Windows:
'use strict';
const assert = require('node:assert');
const { execFileSync, spawnSync } = require('node:child_process');
const {
cpSync,
existsSync,
mkdirSync,
rmSync,
writeFileSync,
} = require('node:fs');
const { tmpdir } = require('node:os');
const { join } = require('node:path');
function run(command, args) {
return execFileSync(command, args, {
encoding: 'utf8',
stdio: ['ignore', 'pipe', 'pipe'],
});
}
function currentWindowsUser() {
return run('whoami', []).trim();
}
function restrictDirectory(dir) {
run('icacls', [dir, '/deny', `${currentWindowsUser()}:(OI)(CI)(RX)`]);
}
function restoreDirectory(dir) {
if (existsSync(dir)) {
run('icacls', [dir, '/remove:d', currentWindowsUser()]);
}
}
if (process.argv[2] === 'child') {
assert.throws(() => {
cpSync(process.argv[3], process.argv[4], { recursive: true });
});
process.exit(0);
}
const root = join(tmpdir(), `node-cpsync-${process.pid}`);
const src = join(root, 'src');
const dest = join(root, 'dest');
const restrictedDir = join(src, 'restricted');
mkdirSync(restrictedDir, { recursive: true });
writeFileSync(join(src, 'readable.txt'), 'readable\n');
writeFileSync(join(restrictedDir, 'blocked.txt'), 'blocked\n');
restrictDirectory(restrictedDir);
try {
const child = spawnSync(process.execPath, [__filename, 'child', src, dest], {
encoding: 'utf8',
});
console.log({
status: child.status,
signal: child.signal,
stdout: child.stdout,
stderr: child.stderr,
});
} finally {
restoreDirectory(restrictedDir);
rmSync(root, { recursive: true, force: true });
}
The important part is that fs.cpSync(src, dest, { recursive: true }) is called without a filter option, so it uses the native copyDir fast path.
How often does it reproduce? Is there a required condition?
It reproduces when the native fs.cpSync() copyDir fast path encounters a filesystem error during directory iteration, path canonicalization, or file type checks.
The fast path is used for recursive directory copies when no filter option is provided. Passing filter: () => true avoids this path and falls back to the JavaScript implementation.
What is the expected behavior? Why is that the expected behavior?
fs.cpSync() should report the filesystem failure as a JavaScript exception that callers can catch with try/catch or assert.throws().
Filesystem APIs should convert native filesystem failures into JavaScript errors instead of terminating the process.
What do you see instead?
Some std::filesystem calls in the native copyDir implementation use throwing overloads. When those operations fail, the C++ exception can bypass Node's normal error conversion.
Instead of a catchable JavaScript exception, the process can terminate in the native layer.
Additional information
This appears to come from src/node_file.cc's CpSyncCopyDir implementation. Some calls already use std::error_code, but others use throwing std::filesystem overloads, including directory iteration and file type/path checks.
The fix is to use non-throwing std::filesystem overloads throughout the copyDir path and convert each failure with ThrowStdErrException.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Windows failure with the script in the issue, then inspect src/node_file.cc and the CpSyncCopyDir implementation. Trace directory iteration, path canonicalization, and file type checks, and verify that filesystem failures become catchable JavaScript exceptions rather than terminating the process.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, javascript, node.js
- Domain
- backend, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 64/100