Rsync 3.4.3 有數百個 Claude 共同署名的 commit （★
61 分）
Jeremiah Fieldhaven 表示，系統升級到 rsync 3.4.3 後，他用於增量備份的流程開始失敗；該流程依賴多個 `--compare-dest` 參數來比對既有備份，只要不是完整備份就會出問題。降回 rsync 3.4.1 後一切恢復正常。他查看 GitHub 原始碼紀錄，因為變更紀錄沒有明顯相關說明，卻發現自 3.4.1 以來有 36 個 commit 署名為「tridge and claude」，因此懷疑 Claude（Anthropic 的大型語言模型 AI 助理）共同參與的變更與這次迴歸有關。
這起事件之所以引發關注，是因為 rsync 是類 Unix 系統中極常用的檔案同步與備份工具，可靠性幾乎就是它的核心價值；若增量備份在特定版本突然失效，對伺服器維運、備份驗證與災難復原都可能造成風險。原帖回覆中有人指向 rsync GitHub issue #915，暗示問題可能已被其他人回報；也有人提到 Andrew Tridgell（常稱 Tridge）是 rsync 原作者，也是 Samba（讓 Unix/Linux 與 Windows 檔案分享協定 SMB 互通的自由軟體）相關的重要人物，因此看到他與 Claude 共同署名的變更引發更大的落差感。
Hacker News 討論中，有人進一步指出目前可見約 130 個 Claude 共同署名的 commit，並批評維護者似乎未充分回應近期 issue，仍持續推進「security in depth」（縱深防禦式資安強化）修補，結果破壞實際功能。也有留言整理多個疑似造成迴歸的 commit 與對應 issue，認為這不是單一案例；另有人補充，3.4.2 可能已包含大量 LLM（Large Language Model，大型語言模型）輔助維護內容，而問題也影響 Debian、Ubuntu 等發行版的回補版本。部分使用者因此建議改用 rclone，或關注以 Go 撰寫、強調記憶體安全的替代實作。
討論並非一面倒反對 AI。有人認為許多 Claude 共同署名的變更集中在測試、CI（Continuous Integration，持續整合）、文件與修補可能造成記憶體毀損或 CVE（Common Vulnerabilities and Exposures，公開資安弱點編號）的問題，不能只因 AI 參與就斷定品質低劣；真正的問題可能是審查、測試與發行控管不足。反方則強調，rsync 這類基礎工具對正確性的要求遠高於一般應用，修補版本不應輕易改變行為，尤其備份工具若發生細微資料或中繼資料錯誤，後果可能比直接失敗更嚴重。整體來看，這場爭議聚焦在開源基礎設施引入 AI 輔助開發時，如何維持可追溯、可審查、可驗證的工程標準，而不是單純的「AI 能不能寫程式」之爭。
👥
44 則討論、評論 💬
https://news.ycombinator.com/item?id=48334021