使用复制的方式转移有严重问题

[zg601x]

你使用的 NAStool 是什么版本，什么环境？

NAStool 版本: v3.3.6

环境: docker版本 和 synology套件版都不正常

你遇到什么问题了？

这个BUG我同时也提交到了 hsuyelin/nas-tools，作者也有回复，但意下似乎并不准备修复

测试了一下，从NT2.X官方版本问题就已经存在了，应该是历史遗留的老问题了

---

问题详细描述：

NT有root权限，版本任何老版本~3.3.9，从用NT的同步功能或者下载器监控转移的功能使用“复制”的方式，从机械盘往固态复制了一千个平均3G的文件，至少损坏几十个影片，损坏的文件表现为：文件大小字节数跟源文件一致，但哈希变了，potplayer或其他任何播放器都播放不了，因为损坏了，开始我以为是什么硬盘坏了，然后试过重装nt、重启系统、重装系统、问题仍旧。

另外，我为了排除是电脑硬解故障，我使用ssh的cp命令，从机械盘大量拷贝同样的资源文件夹 到固态同样文件夹的子文件夹下，测试样本大约5T - 1300部影片， 使用哈希校验工具自动逐个扫描， 结果是：一个都没损坏！

---

之所以我会使用“复制”这种方式来整理文件，而且这么久才发现这个问题，是因为我最近要把下载到本地的文件备份一份到网盘，转移到固态的副本文件路径是我的网盘的同步路径，网盘同步完成自动删除固态本地文件，实际上，刮削复制，移动，硬链接，这几种方式我都会用，说明原版内置这些不同的转移方式都是有其作用的，很可惜原版已经停更了，要不然我会第一时间把问题提交，甚至连我用不到的Mini复制，Rclone复制的这种强大的功能都有。

是否已经浏览过Issues、Wiki及TG公众号仍无法解决？

这个上古问题好像我是第一个发现

你期望的结果

当然是希望未来更新版本能得到修复

给出程序界面截图、后台运行日志或配置文件

nt日志都挺正常的，显示转移成功了，实际是否损坏了，nt并不知道

其它问题提供后台日志，如为Docker请提供docker的日志

[Mattoids]

你的意思是nt在大批量进行复制操作的时候会导致部分文件的哈希值发生变化而导致文件损坏对吗？
这可能需要你能给出详细的操作说明才有可能进行修复。

[zg601x]

问题重现方式：打开NT web界面-媒体管理-文件管理，选中的电视剧主文件夹或者电影主文件夹，右上方-转移，转移方式：复制，（其实使用自动化操作的“下载文件转移：复制” 和 “目录同步，同步方式：复制”，也可以，我发现问题就是用这样的方式管理影片时，客户端看不了个别影片资源，找到问题源头是NT的 复制转移方式）

我这边源文件路径是在机械硬盘，目标路径是固态硬盘，复制转移过程中，系统资源占用并不高，但文件损坏率很高，有时接连两个文件损坏了，有时两部电视剧集复制完后发现都没损坏，但测试了不下于五遍，每次使用复制转移来操作1TB左右的文件，至少也有十个媒体文件不正常。

[Mattoids]

好的，如果可以复现的话，下个版本会尝试修复的

[zg601x]

好的。谢谢

[zg601x]

好的，如果可以复现的话，下个版本会尝试修复的

大佬，终于看到新版本了，可是......下个版本有希望修复吗

[Mattoids]

这个问题一直没有复现，恐怕不好解决

[zg601x]

把copy方式改成rsync就行了，我已经解决了。对了，你有没有能力把nt自带的rclone copyto改成多进程？默认是单线程，而rclone是一个单线程堵塞命令行程序，改成双进程能解决单个任务堵塞的问题，某些情况下能大幅提高传输性能。