跨分区重命名本质是拷贝+删除，因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 shutildef 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 操作，中间窗口期极难控制。
