Repository navigation
vfs: RealFSProvider readFileSync(fd) fails after backing file is renamed #64103
Description
Version
main
Platform
macOS 26.5.0
Subsystem
vfs
What steps will reproduce the bug?
import fs from 'node:fs';
import os from 'node:os';
import path from 'node:path';
import vfs from 'node:vfs';
const realRoot = fs.mkdtempSync(path.join(os.tmpdir(), 'vfs-real-root-'));
const mountPoint = fs.mkdtempSync(path.join(os.tmpdir(), 'vfs-mount-'));
const mounted = vfs
.create(new vfs.RealFSProvider(realRoot), { emitExperimentalWarning: false })
.mount(mountPoint);
try {
fs.writeFileSync(path.join(realRoot, 'a.txt'), 'still readable');
const fd = fs.openSync(path.join(mountPoint, 'a.txt'), 'r');
fs.renameSync(path.join(realRoot, 'a.txt'), path.join(realRoot, 'b.txt'));
try {
console.log(fs.readFileSync(fd, 'utf8'));
} finally {
fs.closeSync(fd);
}
} finally {
mounted.unmount();
fs.rmSync(realRoot, { recursive: true, force: true });
fs.rmSync(mountPoint, { recursive: true, force: true });
}How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
It should print still readable. An already-open fd should remain usable after the file is renamed, matching native filesystem behavior.
What do you see instead?
fs.readFileSync(fd, 'utf8') throws ENOENT after the backing file is renamed. This shows RealFSProvider is trying to read through the original path.
Additional information
No response
Activity
trivikr commentedon Jun 24, 2026
Equivalent in fs
This outputs
still readable[-]node:vfs RealFSProvider readFileSync(fd) fails after backing file is renamed[/-][+]vfs: RealFSProvider readFileSync(fd) fails after backing file is renamed[/+]vfs: read RealFSProvider files from open fd
vfs: read RealFSProvider files from open fd
vfs: write RealFSProvider files to open fd
vfs: write RealFSProvider files to open fd