文件重命名检测——GoodSync 如何识别移动和重命名

问题：重命名被当作删除+新增

假设你在源端把 project/report-final.docx 重命名为 project/report-v2.docx：

• 普通工具的行为：检测到旧文件消失（删除操作）+ 新文件出现（新增操作）→ 删除旧文件 + 复制新文件
• GoodSync 的行为：通过内容哈希对比，识别出两个文件内容完全相同，只是名字变了 → 执行一次 Rename/Move 操作

两种行为的差异：

重命名检测的实现原理

GoodSync 在每次 Analyze 时会计算两侧所有文件的内容哈希（默认 MD5，可切换），并维护一个内部的文件身份索引。当发现：

• 左侧某个文件被标记为「已删除」（对比上次分析的文件列表）
• 同时右侧出现一个新文件（同样对比列表）
• 两个文件的内容哈希完全相同

GoodSync 就会判断：这不是「删除 + 新增」，而是「某个文件被重命名了」。

重命名检测不仅能识别文件级别的重命名，还能检测到：

• 文件夹重命名：整个目录被重命名，GoodSync 识别为 Rename Folder，内部文件不需要重新传输
• 跨目录移动：文件从 folderA/ 移动到 folderB/，同样可以识别为 Move，而不是 Delete + Copy
• 批量重命名：多个文件同时被批量重命名（如批量加上前缀），GoodSync 也能逐个匹配

在分析结果中的展示

重命名/移动操作在分析结果树中会有专门的标记：

# 普通删除+新增（没有被识别为重命名）：
左侧: report-final.docx  ⊘  (会被删除)
右侧: report-v2.docx      ↓  (会被复制)

# 识别为重命名（GoodSync 检测到内容相同）：
左侧: report-final.docx  ↻  →  右侧: report-v2.docx  (只执行重命名)

↻ 符号代表「检测到重命名或移动，将执行 Move 操作」。带宽消耗为零——GoodSync 只在文件系统层面改路径，不传输文件内容。

重命名检测的局限性

重命名检测虽然智能，但也有边界：

检测窗口依赖历史状态

GoodSync 的重命名检测依赖于上一次分析的文件列表快照。如果两次同步间隔很长（比如几周），期间有大量文件变动，可能会出现：

• 旧文件被删除了很久，新文件才被创建 → GoodSync 无法关联它们
• 这种情况下会退化为 Delete + Copy

同时修改内容 + 重命名

如果在同一个操作中既改了文件名又改了文件内容，GoodSync 无法判断这是「重命名 + 内容变更」还是「删除旧文件 + 创建新文件」——此时会按修改时间和内容差异做最佳猜测，但大概率会执行一次 Copy（因为内容不同了）。

大量文件同时重命名

极端场景下——比如一个包含 10 万个文件的目录整个被重命名——GoodSync 需要计算所有文件的哈希来匹配。这个过程本身会有计算开销，耗时可能比直接复制还长。但 GoodSync 在检测到这种极端场景时会自动切换策略，不会死磕重命名检测。

版本历史中的表现

当 GoodSync 识别到一次 Move/Rename 操作后：

• 版本历史中会记录为「report-final.docx 重命名为 report-v2.docx」
• 原文件的历史版本（如果有的话）会迁移到新名下
• 不会产生「旧文件被删除」的版本历史快照

手动强制 Move（进阶）

如果你明确知道某个文件是被移动了，但 GoodSync 没有自动识别出来，可以在分析结果树上：

1. 右键点击被删除的旧文件
2. 选择「Change Action」→「As Move To...」
3. 选择对应的新文件

这样 GoodSync 就会把这个操作标记为 Move，而不是 Delete + Copy。不过这种手动操作在实际中很少用到——GoodSync 的自动检测覆盖度已经很高了。