微云的文件校验秒传功能不完善

ottioca

本帖最后由 ottioca 于 2016-8-8 20:36 编辑

之前有个文件分了几个压缩包穿到微云，刚刚下载回本地解压失败。幸好当时用quickpar做了par2修复文件，终于查看出有一个包损坏了一点点，并修复了压缩包。
但是，将修复好的那个压缩包补传到微云的时候，居然是秒传。把这个刚秒传的包再下载并hash之后，发现特征值和前面那个损坏的包是一致的……
我想这个现象应该说明微云的文件校验秒传功能不完善，可能在校验的时候并不是将整个文件完整校验。
提醒大家注意一下这个BUG可能导致的一些问题和风险。

总是吵架的猪

以前迅雷的就有人专门研究过 截取文件一部分做md5校验 整个文件估计速度太慢了 百度云也是这样

睡在键盘上

想多了。你自己也说了，是修复了压缩包。
压缩包里的文件没有变化的

ottioca

本帖最后由 ottioca 于 2016-8-8 19:01 编辑

睡在键盘上 发表于 2016-8-8 18:53

想多了。你自己也说了，是修复了压缩包。
压缩包里的文件没有变化的

修复后的包可以秒传，但是这个新秒传的包再次下载后，和损坏的包hash值相同。

损坏的包是如何造成的无从考证了，这里也不讨论。

简单说就是把 “损坏包”修复成“正确包”之后，“正确包”可以秒传；但是这个秒传后的“正确包”重新下载后，却跟“损坏包”是相同的。

呵呵

hash算法的问题吧……

ottioca

呵呵 发表于 2016-8-8 19:04

hash算法的问题吧……
MD5、 SHA1 和 CRC32 三种算法都用了，情况一致。

雨宫音羽

因为应该是所谓的微特征。。截取文件特定位置特定大小的地方进行hash 然后和数据库里比对 这样效率高

ottioca

雨宫音羽 发表于 2016-8-8 19:48

因为应该是所谓的微特征。。截取文件特定位置特定大小的地方进行hash 然后和数据库里比对 这样效率高 ...
可能微云是这么计算的。这种情况下，如果文件在传输的过程中，或者服务器那边存储的时候，出了一点小错误，那么正确的文件再传也都是秒传，没法替换掉错误文件了。我用quickpar修复的时候，检测到错误的文件只有一段（整个文件划分了超过50段）。

musics

微秒传，很有可能不是文件完整的检查。取的某个区块也有可能

KKhostRuclinux

会不会本身电脑有问题？
总是吵架的猪 发表于 2016-8-9 01:47

以前迅雷的就有人专门研究过 截取文件一部分做md5校验 整个文件估计速度太慢了 百度云也是这样 ...
顶这个