计算技术 · 实用指南
Linux 提示“Invalid cross-device link”？先证明挂载边界，再决定重命名、复制还是发布
EXDEV 是契约警告，不是路径字符串谜题。先在调用进程的挂载命名空间中映射两端，再判断是否必须原子重命名；若需跨文件系统复制，应在删除源之前于目标端暂存、校验并完成本地重命名。
Linux 在 rename 无法于同一已挂载文件系统内完成移动时返回 EXDEV，常显示为“Invalid cross-device link”。目录名看似相关，也可能因绑定挂载、容器卷、tmpfs、overlay 层或独立文件系统而属于不同挂载身份。修改代码或权限前，必须从失败进程所在的同一挂载命名空间检查两条路径。
跨文件系统的降级方案并不是伪装的 rename，而是复制、验证以及成功后才删除源。如果读者绝不能看到半成品，应在目标文件系统写入临时对象，刷新并核验，再在同一目标挂载内把临时名重命名为最终名。只保留工具和目标真正支持的元数据，并明确说明整个跨挂载移动并非原子操作。
1. 记录失败操作及其命名空间
记录真实调用者的准确源路径、目标路径、进程身份、容器或服务环境以及返回的错误。若故障发生在容器或私有挂载命名空间，不能只在主机 shell 复现，因为同一字符串可能对应另一份挂载表。
还要说明这是普通搬移、替换已有名称，还是向读者承诺全有或全无的发布步骤。这个要求决定复制再删除是否可以接受。
2. 把两条路径映射到挂载身份
在调用者的命名空间对源和目标目录运行 findmnt --target。调查另一进程时，可在权限允许的情况下使用 findmnt --task PID 或读取 /proc/PID/mountinfo。比较挂载 ID、根、挂载点、文件系统类型和来源，不要依赖目录前缀。
如果最终文件尚不存在，就解析其父目录。绑定挂载可能显示相同底层设备却拥有不同挂载身份；rename(2) 也明确指出，即使同一文件系统挂载在两个位置，跨已挂载文件系统的重命名仍可能被拒绝。
3. 决定操作真正需要的保证
若操作必须是一次原子命名空间变更，就让临时名和最终名位于同一挂载，并在该处使用 rename。应重新配置临时目录、工作区、卷或发布暂存路径，而不是盲目加入跨文件系统复制。
若允许短暂重复和整体非原子移动，复制流程可以正确，但必须写明保证。目标通过核验之前，始终把源视为权威副本。
4. 在目标文件系统暂存并校验
在目标目录创建唯一临时名，复制数据，按持久性策略关闭并刷新，再核验大小或密码学摘要。还要检查应用依赖的元数据：模式、所有者、时间戳、ACL、扩展属性、符号链接身份和稀疏分配并非所有复制方法都能保留。
核验后，将目标端临时对象重命名为最终名。因为两个名称在同一挂载上，最后这次重命名可以是原子的。删除原件之前，确认最终对象及其访问策略。
5. 测试故障边界，而不是隐藏 EXDEV
分别测试复制完成前中断、核验后中断、目标端本地重命名后中断，以及删除源之前中断。恢复程序应能安全识别残留临时目标、完整最终目标加未删源，以及进程崩溃后的重试。
不要通过改权限、重复同一个 rename 或吞掉错误来“修复” EXDEV。它证明所要求的原子契约跨越了挂载边界；应改用明确记录强弱保证的工作流。
