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.
Version
v22.17.0 and later; verified against v27.0.0-pre built from current main.
Platform
Subsystem
fs
What steps will reproduce the bug?
Run this script on Windows:
The important part is that
fs.cpSync(src, dest, { recursive: true })is called without afilteroption, 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
filteroption is provided. Passingfilter: () => trueavoids 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 withtry/catchorassert.throws().Filesystem APIs should convert native filesystem failures into JavaScript errors instead of terminating the process.
What do you see instead?
Some
std::filesystemcalls 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'sCpSyncCopyDirimplementation. Some calls already usestd::error_code, but others use throwingstd::filesystemoverloads, including directory iteration and file type/path checks.The fix is to use non-throwing
std::filesystemoverloads throughout the copyDir path and convert each failure withThrowStdErrException.