rsync 2.6.9 故障及 3.4.1 修复 | AI生成和翻译

Home 2026.06

为什么 rsync 2.6.9 会失败：

macOS 自带 rsync 2.6.9（自 2006 年起，Apple 从未更新过它）。它存在几个关键的错误/限制：

  1. I/O 超时处理有缺陷 —— rsync 2.6.9 有一个内部 I/O 超时（与 --timeout 不同）。当发送方正在构建文件列表或传输数据时，接收方期望定期收到ping。在慢速机器（旧 MacBook Pro HDD）上，或传输数百万个小文件（node_modules、Photos original）时，发送方会卡在扫描文件系统上，无法及时发送ping。接收方会中断连接 → io timeout after 1912 seconds -- exiting。

  2. 没有正确的 SSH 多路复用 —— rsync 2.6.9 打开单个 SSH 连接并通过它推送所有数据。当连接停滞（WiFi 中断、TCP 缓冲区满、路由器 NAT 超时）时，没有恢复机制。管道中断 → Broken pipe (32)，code 255。

  3. 没有增量文件列表传输 —— rsync 2.6.9 先在发送方构建完整的文件列表，然后一次性发送。对于包含 20,000+ 个文件的项目，这意味着超过 30 分钟的暂停，期间没有实际文件数据流动。在此暂停期间，SSH 连接空闲，路由器/操作系统会将其终止。rsync 3.x 增量地流式传输文件列表——数据立即开始流动。

  4. 符号链接处理更差 —— rsync 2.6.9 在文件列表阶段跟踪并重新解析符号链接，这在处理 node_modules（数千个符号链接）时极慢。每个符号链接解析都是在旧 HDD 上的一次独立 stat() 调用。

为什么 rsync 3.4.1 解决了问题：

  1. 更好的 SSH 保活 —— rsync 3.x 在所有阶段（文件列表构建、传输）发送协议级别的保活 ping。即使在长时间暂停期间，连接也能保持活动。

  2. 增量文件列表 —— rsync 3.x 一旦发现文件就开始传输，而不是等待完整的文件列表。数据从第一秒就开始流动。

  3. 更好的错误恢复 —— rsync 3.x 能通过 --partial --append-verify 更可靠地恢复部分传输。当连接确实断开时，它会从字节级别（而不是文件级别）断点续传。

  4. 更快的校验 —— rsync 3.x 拥有更好的增量传输算法，因此对已传输文件的增量同步几乎是即时的。

  5. 协议版本 32 对比 29 —— rsync 3.x 使用协议 32，它在 SSH 隧道上具有更好的流量控制和拥塞处理。

结果：使用 2.6.9 时，每次大文件传输（项目、图片）都会出现 code 255。使用 3.4.1 时，项目一次性完成，图片在 3 次运行中完成（而且即使在这些运行中，16 个子目录中也只有少数几个子目录出现中断）。

Back Donate