我注意到一个奇怪的问题,即 rsync 无法传输大型文件(大约 >3GB)。我正在运行 MSYS rsync,并通过 ssh 在 LAN 上从我的 Windows 机器传输到我的基于 Linux 的 NAS。大多数文件传输都没有问题,但对于大型文件,我在目标上看到了文件名,但它的大小显示为 0KB,并且文件无法打开。
当我启用详细输出时,我没有看到任何错误,除了关于几个不相关文件的长文件路径的注释。这是我的命令(添加了换行符以便于阅读):
rsync -avv -e 'ssh' --hard-links --inplace --no-inc-recursive
--modify-window=2 --delete --delete-excluded --exclude=".svn*"
"/d/All Files" user@local_ip:"/mnt/All Files"
有人见过这样的事情吗?我该怎么做才能调试它?
更新:--progress
这是启用和 的传输的 rsync 的详细输出--stats
。文件“未压缩的 1080 vs 720.avi”是问题文件。它几乎有 7GB。对我来说奇怪的是 rsync 报告的文件大小为负数。这可能是什么原因造成的?
building file list ...
3 files to consider
delta-transmission enabled
Uncompressed 1080 24p vs 24pa 29 97.avi is uptodate
Uncompressed 1080 vs 720.avi
-1546369996 100% 0.00kB/s 0:00:00 (xfer#1, to-check=0/3)
total: matches=0 hash_hits=0 false_alarms=0 data=-1546369996
Number of files: 3
Number of files transferred: 1
Total file size: 4868647526 bytes
Total transferred file size: 2748597300 bytes
Literal data: -1546369996 bytes
Matched data: 0 bytes
File list size: 124
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 180
Total bytes received: 37
sent 180 bytes received 37 bytes 39.45 bytes/sec
total size is 4868647526 speedup is 22436163.71
答案1
听起来 rsync 使用有符号的 32 位整数来存储文件大小,而您的文件太大以至于该值看起来为负数。
如果您使用的是 64 位机器,请查看是否可以找到 64 位版本的 rsync。如果没有,请尝试其他 rsync 实现(我想到的两个是 DeltaCopy 和 cwRsync)。我怀疑所有这些 rsync 实现都只是相同代码的移植,但值得一试。提供 DeltaCopy 的公司有一款受支持的商业产品,可能会解决您的问题。
市面上有很多文件复制程序,既有免费的也有商业的,所以一定有一个可以解决你的问题。SyncBack 就是一个例子(有免费版和商业版)。
答案2
我以前总是遇到这个问题。我以为他们现在可能已经解决了。
问题曾经是 rsync 在处理大文件时会耗尽内存。几年前我因为这个原因放弃了使用它,转而使用其他备份/同步工具。
不确定 Windows 版 rsync 的状态,是否值得尝试寻找替代二进制文件?