1.首先,我觉得,任何文件传输软件,在开了校验功能后,那么传输文件的流程,应该是这样的:
A.把文件,从 src 位置传输到 dest 位置。
B.把 dest 的文件,读回来,与 src 进行对比。 对比有很多种方式,比如逐字节对比,或者 hash 对比,等等。但无论如何,文件传输软件,需要一个把文件从 dest 读回来的过程。
比如 Windows 上的文件传输软件 FastCopy 或 TeraCopy ,在勾选校验功能后,在完成文件复制后,都会有一个文件校验过程。
2.rsync 的问题。
OS Version: Debian 11 (bullseye)
rsync Version: version 3.2.3 protocol version 31
command: rsync --verbose --checksum --links --keep-dirlinks --hard-links --executability --sparse --checksum-choice=xxh128 --ignore-times --human-readable --progress /srcHostPath root@DestHostIP:/destHostPath
用它传一个 GB 大小的文件。
我专门指定了参数 checksum ,来让它进行校验。
问题是,开了这个参数后,传输前,会等待很长一段时间,感觉像是 rsync 在读取文件进行校验,但我不知道为啥要这么设计。
在传输完成后,整个复制过程就完成了,感觉 rsync 并没有把该文件,从 dest 再读取回来,进行验证。
请问是我参数用错了?还是 rsync 在打开校验参数后,并没有在文件传输完成后进行校验?
1
neteroster 2022-11-06 15:38:59 +08:00 via Android 1
"checksums are always used on the data transferred between the sending and receiving rsync processes. ...
Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check. " ref: https://unix.stackexchange.com/questions/30970/does-rsync-verify-files-copied-between-two-local-drives TLDR: rsync 的校验是作用在传输过程的,而不考虑写入磁盘后的情况 |
2
smallthing 2022-11-06 15:40:01 +08:00
学会看文档
-c, --checksum: skip based on checksum, not mod-time & size This forces the sender to checksum every regular file using a 128-bit MD4 checksum. It does this during the initial file-system scan as it builds the list of all available files. The receiver then checksums its version of each file (if it exists and it has the same size as its sender-side counterpart) in order to decide which files need to be updated: files with either a changed size or a changed checksum are selected for transfer. Since this whole-file checksumming of all files on both sides of the connection occurs in addition to the automatic checksum verifications that occur during a file's transfer, this option can be quite slow. Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking its whole-file checksum, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer "Does this file need to be updated?" check. |
3
MrKrabs 2022-11-06 15:55:18 +08:00
rclone 好像有校验
|
4
documentzhangx66 OP @neteroster 谢谢,破案了..
|
5
shijingshijing 2022-11-06 16:58:36 +08:00
这个问题其实我也关注了很久,不知道有什么比较好的工具,除了你上面提到的,还有个跨平台的 FreeFileSync ,这个有两个问题:
1 ,Win 系统和 Linux 系统同步的时候,不知道什么原因速度贼慢,专门用了网线链接,两个系统也显示是 1Gbps ,实际速度 100M 都不到。 2 ,他家的校验有人提过这个 feature ,但我之前在论坛上看他们讨论,你捐赠了提个 issue 上去就给你需要的 feature 提高优先级,否则会被 backlog 一直压着,这个操作怎么说,感觉也没毛病。。。 还有一点作为一个强迫症比较难以接受的是,很多同步软件会丢掉文件的创建时间,修改时间,统一改成同步时创建文件的时间,目前我的操作是用 7zip 打个 tgz 包,然后拷贝过去再解压,这样时间保持不变。FreeFileSync 这方面是不保留时间的,他们论坛的人讨论出的解决方案是用脚本单独处理,传输前扫描文件,保存时间信息到一个文件,传输完成后这个信息文件也传过去,根据保存的信息再批量修改时间。 不知道还有没有其他更好的工具或者方法。 |
6
oxromantic 2022-11-06 22:47:26 +08:00
@shijingshijing 印象中 rsync -a 不就可以保留时间戳么?
|
7
smallthing 2022-11-08 03:22:04 +08:00
@shijingshijing 1.关闭加密看看
2.除了 ctime 都可以保留吧? |