如何安全重命名文件并处理跨分区情况

跨分区重命名本质是拷贝+删除，因rename()系统调用仅同文件系统内原子执行，跨挂载点返回EXDEV错误；mv命令自动fallback，编程需显式捕获errno.EXDEV并处理。

重命名操作本质是 rename() 系统调用，跨分区会失败

Linux/macOS 下 rename() 仅在同文件系统内原子完成；一旦源路径和目标路径位于不同挂载点（比如 /home 和 /mnt/usb），系统直接返回 EXDEV 错误。这不是权限问题，而是内核限制——跨设备无法硬链接复用 inode，必须拷贝+删除。

用 mv 命令时自动 fallback 到拷贝+删除

GNU coreutils 的 mv 已内置处理逻辑：先尝试 rename()，失败且错误为 EXDEV 时，自动改用 cp -f + rm -f 组合。但要注意：

• 目标目录必须有写权限，且磁盘空间需足够容纳副本
• 若源文件被其他进程写入，拷贝过程中可能产生不一致（mv 不加锁）
• 大文件跨分区移动会明显变慢，且中断后残留临时文件风险高
• macOS 的 mv 行为类似，但某些 BSD 变种不自动 fallback，需手动判断

编程中安全重命名需显式检查 EXDEV

Python 示例（使用 os.rename()）：

import os
import shutil
def safe_rename(src, dst):
try:
os.rename(src, dst)
except OSError as e:
if e.errno == errno.EXDEV:
shutil.copy2(src, dst)  # 保留时间戳和权限
os.unlink(src)
else:
raise

关键点：

• 必须捕获 OSError 并检查 e.errno == errno.EXDEV，不能只靠异常类型
• shutil.copy2() 比 copy() 更安全，它复制元数据（mtime/ctime/mode）
• 若 unlink() 失败（如权限不足），已拷贝的 dst 会残留，需额外清理逻辑

注意硬链接、符号链接和特殊文件系统的边界

情况

跨分区重命名还涉及更隐蔽的问题：

• 源或目标是符号链接时，mv 默认操作链接本身而非目标文件
• 源是硬链接且跨分区移动，新位置将失去原有链接关系（inode 不同）
• NFS 或 FUSE 文件系统可能伪造 EXDEV 或表现异常，建议先用 stat -c '%d' path 比较设备号
• 容器环境（如 Docker）中，绑定挂载的目录可能看似同分区，实则跨 mount namespace，行为不可靠

真正麻烦的不是“能不能动”，而是“动完状态是否可预期”——尤其当文件正被日志轮转、数据库写入或 rsync 同步时，跨分区 rename 实质是两次 I/O 操作，中间窗口期极难控制。