Node.js fs.renameSync重命名目录是否为防损坏的原子操作？

const path = require('path');
const fs = require('fs');
const os = require('os');

const from_dir = path.resolve(os.homedir(), './from_dir');
const to_dir= path.resolve(os.homedir(), './new_dir');
fs.renameSync(from_dir, to_dir);

fs.renameSync是直接透传操作系统原生rename系统调用的接口，只要from_dir和to_dir处于同一个文件系统/磁盘卷下，完全可以依赖操作的原子性，哪怕进程在执行过程中被强制终止，也不会损坏from_dir的原有内容，提前做备份是完全多余的。

• 同文件系统下的目录重命名，根本不会移动任何实际的文件数据块，也不会修改目录内部的文件列表、权限等元数据，仅会修改父目录下的两条目录项：
  • 删除原来指向from_dir的目录条目
  • 新增一条指向同一个目录inode的to_dir目录条目
• 整个修改过程由操作系统内核保证原子提交：要么两个操作全部完成（重命名成功），要么全部不生效（和没调用过该接口完全一致），不存在半完成的中间状态。
• 即便Node.js进程在系统调用执行的瞬间被强制kill、触发信号终止，已经进入内核态的操作不受用户态进程生命周期的影响，最终结果只有两种：要么原from_dir完好保留，要么重命名完成、to_dir的内容和原目录完全一致，不会出现目录损坏、内容丢失的情况。
• 不管是Linux、macOS等POSIX兼容系统，还是Windows系统，同卷下的重命名操作都提供了对应的原子保证，Node.js的接口封装没有破坏这一特性。

只有当from_dir和to_dir不在同一个文件系统/磁盘卷时，操作系统才会把rename操作拆解为「全量复制源目录到目标路径→校验完成后删除源目录」的流程，这时候如果进程中断，才可能出现源目录残留、目标目录有残缺数据的问题。但你代码里的两个路径都指向用户home目录下，常规部署场景下必然属于同一个文件系统，不会触发这种跨盘逻辑。

• 常规业务开发场景：完全没必要提前执行cp -r ~/from_dir ~/from_dir_backup这类备份操作，额外的复制流程反而会占用磁盘IO、拉长操作窗口，没有实际收益。
• 如果你处理的是核心生产环境的关键目录，没法保证两个路径一定处于同卷，或者需要防范磁盘物理坏道、意外掉电这类超出进程控制范围的极端问题，增加备份逻辑属于兜底防护，并不是为了规避rename操作本身的风险。

你之前复现不出异常场景是正常的，操作系统的原子性设计本身就是为了规避这类中断场景的不一致问题，普通的进程终止根本无法触发损坏的结果。

内容的提问来源于stack exchange，提问作者spider monkey