一样的文件任然计算出了差异

[meilaopo]

有2个相同文件（30GB+），分别计算出hash是完全一样的，diff步骤仍然返回了差异

[sisong]

当前是这样的(即完全相同的数据也可能需要下载少量block块)，这是算法为了优化速度而放弃了少量几率的匹配。
. 最可能的一处： #define kIsSkipMatchedBlock true
每当一个block块匹配成功后，就会跳过block长度字节的old数据位置。如果将true改成false，就会只前进1个字节位置，这样就不会漏匹配了。
. 可能性较小的另一处： static const int kMatchHitOutLimit =16;
这里控制粗匹配的查询深度，避免某些"畸形"数据将算法复杂度退化为O(N^2)。理论上不控制查询匹配深度才能保证不漏过任何可能的匹配。

[meilaopo]

当前是这样的(即完全相同的数据也可能需要下载少量block块)，这是算法为了优化速度而放弃了少量几率的匹配。 . 最可能的一处： #define kIsSkipMatchedBlock true 每当一个block块匹配成功后，就会跳过block长度字节的old数据位置。如果将true改成false，就会只前进1个字节位置，这样就不会漏匹配了。 . 可能性较小的另一处： static const int kMatchHitOutLimit =16; 这里控制粗匹配的查询深度，避免某些"畸形"数据将算法复杂度退化为O(N^2)。理论上不控制查询匹配深度才能保证不漏过任何可能的匹配。

修改之后会大幅提高计算时间吧？

[sisong]

是的，这也是权衡过后的设置。某些情况时间可能加倍或更多，你可以修改试试看。

[meilaopo]

支持原地更新吗，类似hdiffpatch那样，文件太大了，写入一次要很久；如果能原地更新少数几个块就快很多了

[sisong]

当前不支持原地更新，HDiffPatch也不支持原地更新啊!
原地更新特性需要单独实现一个复杂的类似磁盘整理或路径规划的算法，或者做更多条件约束。

[meilaopo]

几年前看到这条 以为已经实现了
sisong/HDiffPatch#36

[meilaopo]

如果计算出需要同步块比率极低，能不能再次对比下old文件的对应位置的hash和index中是否一致，应该很快的。

[sisong]

谢谢你对此(相同数据也下载)的反馈，我尝试修改了一下匹配和跳过block块的逻辑，但最后没能找到更好的方案；
你可以下载新的代码，然后将 kIsSkipMatchedBlock的默认值1修改为3，就能在大部分情况下不会生成下载块。
注意：即使修改后，相同数据某些情况还是会生成下载块；而且速度平均可能有5%的下降，多线程下速度影响会小一些。