我做了一个很极端的测试：

测试环境：

电信宽带 300M ；

Intel i7-10710u, 64G DDR4-2400，1T SN550 SSD;

Synology DS1918+ w/ 4T 红盘*4 RAID5;

天翼云盘客户端（ windows ）当下最新版（ v6.2.3 ）

数据来源

通过 rsync 方式同步一份 http://mirror.rackspace.com/centos-vault 下的文件，因为比较大，所以我只选择了这几个子目录：

http://mirror.rackspace.com/centos-vault/6.6

http://mirror.rackspace.com/centos-vault/6.7

http://mirror.rackspace.com/centos-vault/6.8

http://mirror.rackspace.com/centos-vault/6.9

http://mirror.rackspace.com/centos-vault/7.3.1611

http://mirror.rackspace.com/centos-vault/7.4.1708

http://mirror.rackspace.com/centos-vault/7.5.1804

http://mirror.rackspace.com/centos-vault/7.6.1810

http://mirror.rackspace.com/centos-vault/7.7.1798

http://mirror.rackspace.com/centos-vault/8.0.1905

因为这些文件内有从 1kb 到 10Gb 的文件，可以模拟各种复杂的文件大小（ yum 源使用就不说了）

上传数据到天翼云盘

因为天翼云盘很不稳定，上传出错后再点继续就会产生一堆被重命名的文件，这是我对其最吐槽的问题，“自作主张”。

所以我很小心逐个将 centos-vault 文件夹下各个子目录逐个拖进天翼云盘客户端，逐个传，如果哪个目录出现错误，或者断流，就整个子目录全部删除后重新再传，通过此行为保证我的操作不会产生重复文件，没办法，重命名整怕了，这是个天翼云盘的巨坑。

就这样连续不停地传我把它们都传到了天翼云盘服务器上了，不过也好，人不花时间，就是把机器一直开着就行了。

下载数据到本地

天翼云盘没有指定文件夹查看该文件夹下文件数量，占用空间，于是我就本地新建一个文件夹，将之前传上去的全部重新取下来，然后检查是否和原始上传文档一致

惨不忍睹的结果

结果大跌眼球：

上传信息

上传的总文件数量：986952 个

上传的总文件夹数量：4405 个

上传的总文件大小：1,324,237,916,221 字节（约 1.20TB ）

下载信息

下载到总文件数量：994131 个

下载的总文件夹数量：4405 个

下载的总文件大小：1,325,886,283,254 字节（约 1.20TB ）

结果

我控制着每次上传都不重复，所以按此来看应该不会产生被重命名的文件，可结果的确是，即便是我每个文件夹一次性成功上传，天翼云盘服务端也会产生一大堆貌似被检测到重名后自作主张进行重命名的文件，结果如下：

产生重名文件数量：7179 个

产生重名文件夹数量：0 个

不一致的字节数差距：1,648,367,033 字节（约 1.53GB ）

部分被重命名的文件信息：

因为它重命名规则大概是：原始文件名(时间戳).原始后缀

所以搜索“(”或者")"就能找出来，结果大部分重命名了一次，也有一小堆（上百个）被重命名了超过 1 次：

如原始文件名：

at-spi-1.28.1-2.el6.centos.i686.rpm

传上去后变成三个：

at-spi-1.28.1-2.el6.centos.i686.rpm

at-spi-1.28.1-2.el6.centos.i686(20200518055049).rpm

at-spi-1.28.1-2.el6.centos.i686(20200518060307).rpm

这行为是什么意思？这是在同一个上传批次里产生的，一个文件居然重名两次！

这是一组较为暴力的测试，排除我很小心避免多次上传同一文件的条件下，还出现这种问题，只能说明天翼云盘在服务端的分布式存储也有很大的隐患（哈希对比，文件分片，文件合并等等）。要拿来珍藏自己的宝贝的得当心了。

天翼云盘很坑