全球主机交流论坛

标题: 微云的文件校验秒传功能不完善 [打印本页]

作者: ottioca 时间: 2016-8-8 18:49
标题: 微云的文件校验秒传功能不完善
本帖最后由 ottioca 于 2016-8-8 20:36 编辑

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

作者: 睡在键盘上 时间: 2016-8-8 18:53
想多了。你自己也说了，是修复了压缩包。
压缩包里的文件没有变化的

作者: ottioca 时间: 2016-8-8 18:57
本帖最后由 ottioca 于 2016-8-8 19:01 编辑

睡在键盘上发表于 2016-8-8 18:53
想多了。你自己也说了，是修复了压缩包。
压缩包里的文件没有变化的

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

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

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

作者: 呵呵 时间: 2016-8-8 19:04
hash算法的问题吧……

作者: ottioca 时间: 2016-8-8 19:42

呵呵发表于 2016-8-8 19:04
hash算法的问题吧……

MD5、 SHA1 和 CRC32 三种算法都用了，情况一致。

作者: 雨宫音羽 时间: 2016-8-8 19:48
因为应该是所谓的微特征。。截取文件特定位置特定大小的地方进行hash 然后和数据库里比对这样效率高

作者: ottioca 时间: 2016-8-8 19:59

雨宫音羽发表于 2016-8-8 19:48
因为应该是所谓的微特征。。截取文件特定位置特定大小的地方进行hash 然后和数据库里比对这样效率高 ...

可能微云是这么计算的。这种情况下，如果文件在传输的过程中，或者服务器那边存储的时候，出了一点小错误，那么正确的文件再传也都是秒传，没法替换掉错误文件了。我用quickpar修复的时候，检测到错误的文件只有一段（整个文件划分了超过50段）。

作者: musics 时间: 2016-8-9 01:36
微秒传，很有可能不是文件完整的检查。取的某个区块也有可能

作者: 总是吵架的猪 时间: 2016-8-9 01:47
以前迅雷的就有人专门研究过截取文件一部分做md5校验整个文件估计速度太慢了百度云也是这样

作者: KKhost 时间: 2016-8-9 01:48
会不会本身电脑有问题？

作者: Ruclinux 时间: 2016-8-9 03:59

总是吵架的猪发表于 2016-8-9 01:47
以前迅雷的就有人专门研究过截取文件一部分做md5校验整个文件估计速度太慢了百度云也是这样 ...

顶这个

欢迎光临全球主机交流论坛 (https://443502.xyz/)