1. 為什么 Windows 上的 rsync 總比 Linux 上事兒多在 Linux 環(huán)境里敲rsync -avz src/ dst/十次有九次順順當(dāng)當(dāng)。換到 Windows 上同樣的命令報(bào)錯(cuò)能給你整出七八種花樣來。這不是 rsync 本身的問題而是 Windows 和類 Unix 系統(tǒng)在文件系統(tǒng)、路徑語義、權(quán)限模型、字符編碼這幾個(gè)底層維度上存在結(jié)構(gòu)性差異rsync 這套為 Unix 設(shè)計(jì)的工具搬到 Windows 上就像把左舵車開到右舵國(guó)家——能開但處處別扭。我這些年幫人排查 Windows 端 rsync 的問題發(fā)現(xiàn)絕大多數(shù)報(bào)錯(cuò)都集中在幾個(gè)固定區(qū)域路徑分隔符與盤符處理、文件權(quán)限與屬性映射、字符編碼與中文文件名、SSH 通道建立、以及大文件與長(zhǎng)路徑支持。這些報(bào)錯(cuò)信息往往只有一行英文新手看了完全摸不著頭腦老手也得愣一下才能定位。這篇內(nèi)容就是把這些年在 Windows 上踩過的 rsync 坑系統(tǒng)梳理一遍從報(bào)錯(cuò)現(xiàn)象倒推根因再給出可復(fù)現(xiàn)的修復(fù)步驟。不管你是用 cwRsync、MSYS2 里的 rsync、WSL 里的 rsync還是 Git Bash 自帶的版本下面這些場(chǎng)景大概率都會(huì)撞上。先說一個(gè)前提認(rèn)知Windows 上跑的 rsync 基本都不是原生 Windows 程序而是通過兼容層Cygwin、MSYS2編譯出來的。這意味著它看到的路徑、權(quán)限、文件系統(tǒng)語義都是兼容層翻譯過的結(jié)果。理解這一層翻譯關(guān)系是讀懂后面所有報(bào)錯(cuò)的關(guān)鍵。很多人一上來就搜報(bào)錯(cuò)原文搜到的答案五花八門卻對(duì)不上自己的環(huán)境就是因?yàn)闆]搞清楚自己用的到底是哪套兼容層。2. 路徑與盤符報(bào)錯(cuò)最密集的重災(zāi)區(qū)2.1 No such file or directory 在文件明明存在時(shí)出現(xiàn)這是 Windows 端 rsync 最高頻的報(bào)錯(cuò)沒有之一?，F(xiàn)象很詭異你在資源管理器里明明看到D:\backup\data這個(gè)目錄命令里也寫了rsync 就是告訴你No such file or directory。根因幾乎總是盤符路徑?jīng)]有被正確翻譯。Cygwin/MSYS2 編譯的 rsync 內(nèi)部期望的是類 Unix 路徑比如/cygdrive/d/backup/data或/d/backup/data而你直接寫D:\backup\data反斜杠會(huì)被當(dāng)成轉(zhuǎn)義字符吃掉盤符冒號(hào)也可能被誤解析。具體表現(xiàn)取決于你用的兼容層兼容層盤符路徑寫法常見誤寫Cygwin (cwRsync)/cygdrive/d/backup/dataD:\backup\dataMSYS2/d/backup/dataD:/backup/data有時(shí)可用但不穩(wěn)WSL/mnt/d/backup/dataD:\backup\dataGit Bash/d/backup/dataD:\backup\data實(shí)操建議在 Windows 端用 rsync路徑一律用正斜杠/并且先確認(rèn)你的兼容層對(duì)應(yīng)的盤符前綴。不確定的話在同一個(gè)終端里敲pwd看當(dāng)前路徑長(zhǎng)什么樣照著那個(gè)格式寫就對(duì)了。另外路徑里帶空格時(shí)務(wù)必用引號(hào)包起來/cygdrive/c/Program Files/data否則空格會(huì)把參數(shù)切斷報(bào)錯(cuò)會(huì)變成多余參數(shù)之類的迷惑信息。還有一個(gè)隱蔽的坑路徑末尾的斜杠語義。src和src/在 rsync 里含義完全不同——前者會(huì)把src目錄本身復(fù)制過去后者只復(fù)制目錄內(nèi)容。這個(gè)規(guī)則在 Windows 上同樣成立但因?yàn)槁窂綄懛ɑ靵y很多人把斜杠問題誤判成了盤符問題排查方向一開始就偏了。2.2 反斜杠引發(fā)的invalid argument連鎖反應(yīng)Windows 用戶習(xí)慣性用反斜杠而反斜杠在 shell 里是轉(zhuǎn)義符。D:\backup傳給 rsync 時(shí)\b可能被解釋成退格符之類的控制字符最終 rsync 收到的是一個(gè)亂碼路徑報(bào)invalid argument或者干脆靜默失敗。更麻煩的是在腳本里。批處理文件.bat里寫路徑反斜杠和正斜杠混用再經(jīng)過 cmd 的解析問題會(huì)層層疊加。我的經(jīng)驗(yàn)是只要涉及 rsync 命令路徑統(tǒng)一用正斜杠腳本里也一樣。如果路徑是從 Windows 程序動(dòng)態(tài)傳進(jìn)來的先在腳本里做一次替換把\換成/把C:換成對(duì)應(yīng)的兼容層前綴。這一步預(yù)處理能消滅掉后面一大半的路徑類報(bào)錯(cuò)。2.3 長(zhǎng)路徑與特殊字符目錄Windows 傳統(tǒng)上對(duì)路徑長(zhǎng)度有 260 字符的限制MAX_PATH雖然新版系統(tǒng)可以通過注冊(cè)表或組策略放開但兼容層編譯的 rsync 未必吃這一套。當(dāng)源目錄層級(jí)很深、文件名又長(zhǎng)時(shí)rsync 遍歷到某個(gè)深層文件就會(huì)報(bào)File name too long或者cannot stat。處理辦法有兩個(gè)方向一是縮短路徑把源目錄挪到層級(jí)淺的位置或者用--relative配合合理的基準(zhǔn)路徑減少冗余層級(jí)二是在兼容層配置里確認(rèn)長(zhǎng)路徑支持是否開啟。實(shí)測(cè)下來最省事的還是縮短路徑因?yàn)榧嫒輰訉?duì)長(zhǎng)路徑的支持參差不齊折騰配置的收益不穩(wěn)定。特殊字符方面Windows 文件名里合法的字符比如、(、)、!在 shell 里有特殊含義。目錄名帶時(shí)命令會(huì)被截?cái)喑蓛啥螆?zhí)行報(bào)錯(cuò)信息完全對(duì)不上真實(shí)原因。這類問題用引號(hào)包裹路徑基本能解決但如果是腳本里批量處理建議對(duì)路徑做統(tǒng)一的引號(hào)包裹處理別指望每個(gè)調(diào)用點(diǎn)都記得加。3. 權(quán)限與屬性Windows 沒有的那套東西3.1 failed to set permissions 與 chmod 相關(guān)報(bào)錯(cuò)rsync 的-a歸檔模式里包含-p保留權(quán)限而 Windows 的 NTFS 權(quán)限模型和 Unix 的 rwx 權(quán)限位根本不是一回事。兼容層會(huì)嘗試做映射但映射不完整于是你經(jīng)?？吹絩sync: failed to set permissions on /cygdrive/d/dst/file.txt: Invalid argument (22)或者rsync: chmod /path/to/file failed: Operation not permitted (1)這類報(bào)錯(cuò)在從 Linux 同步到 Windows 時(shí)尤其常見因?yàn)樵炊藥е暾?Unix 權(quán)限位目標(biāo)端根本表達(dá)不了。根因是兼容層對(duì) chmod 的支持是盡力而為某些權(quán)限組合它映射不了就直接報(bào)錯(cuò)。修復(fù)思路分場(chǎng)景如果目標(biāo)端是 Windows 本地盤權(quán)限本來就沒有保留意義直接去掉-p用-rlt代替-a保留遞歸、鏈接、時(shí)間戳不碰權(quán)限。如果確實(shí)需要保留權(quán)限信息比如目標(biāo)是網(wǎng)絡(luò)共享上的類 Unix 存儲(chǔ)那就得確認(rèn)兼容層的權(quán)限映射配置必要時(shí)用--chmod參數(shù)做顯式轉(zhuǎn)換比如--chmodDurwx,Dgorx,Furw,Fgor把權(quán)限統(tǒng)一壓成一套 Windows 能接受的組合。提示-a是個(gè)全家桶在 Windows 場(chǎng)景下經(jīng)常是麻煩的來源。我一般建議新手在 Windows 端先用-rlt跑通確認(rèn)沒問題后再按需逐項(xiàng)加參數(shù)而不是一上來就-avz全套招呼。3.2 時(shí)間戳同步失敗與failed to set times-t參數(shù)保留修改時(shí)間這個(gè)在 Windows 上大部分情況能用但跨文件系統(tǒng)時(shí)會(huì)翻車。典型報(bào)錯(cuò)rsync: failed to set times on /cygdrive/e/dst/file: Operation not permitted (1)原因通常是目標(biāo)文件系統(tǒng)不支持精確到秒的時(shí)間戳設(shè)置或者文件被其他進(jìn)程占用導(dǎo)致屬性寫入失敗。FAT32/exFAT 的時(shí)間戳精度和 NTFS 不同跨這兩種文件系統(tǒng)同步時(shí)尤其容易觸發(fā)。另外如果目標(biāo)文件正在被某個(gè)程序打開比如殺毒軟件正在掃描設(shè)置時(shí)間戳也會(huì)失敗。排查時(shí)先確認(rèn)目標(biāo)盤的文件系統(tǒng)類型FAT32 的話基本無解只能接受時(shí)間戳不準(zhǔn)或者去掉-t。NTFS 上遇到這個(gè)報(bào)錯(cuò)優(yōu)先懷疑文件占用關(guān)掉可能掃描目標(biāo)目錄的安全軟件再試。還有一種情況是兼容層的時(shí)間戳轉(zhuǎn)換有 bug換一個(gè)版本的 rsync比如從 cwRsync 換到 MSYS2 的版本可能就正常了這個(gè)只能靠試。3.3 符號(hào)鏈接報(bào)錯(cuò)symlink has no referentWindows 的符號(hào)鏈接需要管理員權(quán)限創(chuàng)建普通用戶跑 rsync 遇到源端有符號(hào)鏈接時(shí)-l參數(shù)會(huì)嘗試在目標(biāo)端重建鏈接結(jié)果權(quán)限不夠報(bào)symlink has no referent或者failed to create symlink。如果目標(biāo)端不需要鏈接語義大多數(shù) Windows 備份場(chǎng)景都不需要直接用--no-links或者干脆不用-a因?yàn)?a含-l讓 rsync 把鏈接當(dāng)普通文件處理。如果確實(shí)需要保留鏈接那就得用管理員權(quán)限運(yùn)行并且確認(rèn) Windows 的開發(fā)者模式或相應(yīng)策略允許創(chuàng)建符號(hào)鏈接。實(shí)測(cè)中備份場(chǎng)景下把鏈接展開成實(shí)際文件內(nèi)容加-L參數(shù)往往比保留鏈接更實(shí)用代價(jià)是可能重復(fù)存儲(chǔ)。4. 編碼與中文文件名看不見的亂碼陷阱4.1 中文文件名變成問號(hào)或亂碼Windows 中文環(huán)境默認(rèn)代碼頁是 GBK936而 rsync 和 SSH 通道通常按 UTF-8 處理。當(dāng)文件名含中文時(shí)編碼不一致會(huì)導(dǎo)致文件名在傳輸過程中被錯(cuò)誤解釋輕則目標(biāo)端文件名亂碼重則 rsync 直接報(bào)Invalid or incomplete multibyte or wide character。這個(gè)報(bào)錯(cuò)信息很直白但修復(fù)要分幾層看。首先確認(rèn)終端本身的編碼在 cmd 里敲chcp如果是 936說明當(dāng)前是 GBK 代碼頁。兼容層MSYS2/Cygwin通常有自己的 locale 設(shè)置需要保證 locale 是 UTF-8比如設(shè)置環(huán)境變量LC_ALLen_US.UTF-8或zh_CN.UTF-8。然后確認(rèn) SSH 服務(wù)端的 locale 也是 UTF-8。三層都對(duì)齊了中文文件名才能正常傳輸。實(shí)操中還有個(gè)坑即使傳輸成功Windows 資源管理器里看文件名正常但用某些工具打開又亂碼這是因?yàn)槲募?nèi)容編碼和文件名編碼是兩回事別混為一談。文件名亂碼看的是文件系統(tǒng)層的編碼轉(zhuǎn)換內(nèi)容亂碼看的是文件本身的字符集排查時(shí)先分清是哪個(gè)層面的問題。4.2 Invalid or incomplete multibyte 的定位方法遇到這個(gè)報(bào)錯(cuò)別急著改全局編碼先用--dry-run加-v跑一遍看是哪個(gè)具體文件觸發(fā)的。定位到文件后用ls或資源管理器確認(rèn)它的真實(shí)文件名編碼。有時(shí)候是文件名里混入了不可見字符比如從網(wǎng)頁復(fù)制粘貼帶進(jìn)來的零寬字符這種文件在 Windows 上看著正常rsync 處理時(shí)就炸了。處理這類臟文件名可以先用腳本掃描目錄把含非 ASCII 或控制字符的文件名列出來人工確認(rèn)后重命名。批量場(chǎng)景下用 Python 的os.listdir配合編碼檢測(cè)能快速篩出問題文件。這一步雖然繁瑣但比在 rsync 報(bào)錯(cuò)里大海撈針高效得多。5. SSH 通道與連接類報(bào)錯(cuò)5.1 connection refused 與 connection timed outWindows 端用 rsync 走 SSH 通道-e ssh時(shí)連接類報(bào)錯(cuò)很常見。connection refused通常是目標(biāo)端 SSH 服務(wù)沒起或者端口不對(duì)connection timed out多半是網(wǎng)絡(luò)層不通或者防火墻攔截。排查順序建議這樣走先在 Windows 端用telnet 目標(biāo)IP 端口確認(rèn)端口通不通新版 Windows 可能沒裝 telnet 客戶端用 PowerShell 的Test-NetConnection也行。端口通了再確認(rèn) SSH 服務(wù)本身是否正常用ssh 用戶目標(biāo)IP手動(dòng)連一次看認(rèn)證環(huán)節(jié)有沒有問題。很多時(shí)候 rsync 報(bào)連接錯(cuò)誤實(shí)際是 SSH 密鑰沒配好或者 known_hosts 里有舊記錄沖突手動(dòng) ssh 一次就能暴露真實(shí)原因。注意Windows 上 rsync 調(diào)用的 ssh 客戶端可能和系統(tǒng)自帶的不是同一個(gè)。兼容層通常自帶一個(gè) ssh路徑優(yōu)先級(jí)搞錯(cuò)的話rsync 用的可能是兼容層里的舊版本 ssh而你以為它用的是系統(tǒng)的。用rsync -e ssh -v可以看到實(shí)際調(diào)用的 ssh 詳細(xì)日志定位版本和配置問題很有效。5.2 密鑰認(rèn)證失敗的隱蔽原因Permission denied (publickey)在 Windows 上有個(gè)高頻隱蔽原因密鑰文件的權(quán)限。OpenSSH 對(duì)私鑰文件的權(quán)限要求很嚴(yán)格Windows 上如果私鑰文件對(duì)其他用戶可讀ssh 會(huì)拒絕使用它。報(bào)錯(cuò)信息不會(huì)直接告訴你權(quán)限太寬只會(huì)說 publickey 認(rèn)證失敗很容易誤判成密鑰沒配對(duì)。修復(fù)方法是收緊私鑰文件權(quán)限右鍵文件屬性安全選項(xiàng)卡里移除繼承只保留當(dāng)前用戶和 SYSTEM 的讀取權(quán)限。命令行下可以用icacls處理icacls C:\Users\你的用戶名\.ssh\id_rsa /inheritance:r icacls C:\Users\你的用戶名\.ssh\id_rsa /grant:r %USERNAME%:R另外密鑰文件的換行符也可能出問題。從 Linux 拷過來的私鑰如果被 Windows 編輯器改成了 CRLF 換行ssh 解析會(huì)失敗。用支持 LF 的編輯器比如 VS Code 切到 LF 模式檢查一下或者用dos2unix類工具轉(zhuǎn)換。5.3 傳輸中斷后的續(xù)傳報(bào)錯(cuò)大文件傳輸中斷后用--partial --progress續(xù)傳Windows 端偶爾會(huì)報(bào)Unexpected remote arg或者文件校驗(yàn)失敗。這通常是因?yàn)橹袛鄷r(shí)目標(biāo)端的臨時(shí)文件狀態(tài)不干凈或者兼容層對(duì)部分文件的處理有偏差。穩(wěn)妥做法是中斷后先刪掉目標(biāo)端的臨時(shí)文件.filename.XXXXXX這種再重新跑續(xù)傳。雖然多花一點(diǎn)時(shí)間但比在損壞的臨時(shí)文件上反復(fù)失敗強(qiáng)。6. 大文件、文件鎖與殺毒軟件干擾6.1 Input/output error 與大文件傳輸傳輸超過 4GB 的單文件時(shí)如果目標(biāo)盤是 FAT32會(huì)直接報(bào)File too large或者Input/output error。FAT32 單文件上限就是 4GB這是文件系統(tǒng)的硬限制跟 rsync 無關(guān)。換成 NTFS 或 exFAT 即可。exFAT 雖然支持大文件但時(shí)間戳精度和權(quán)限支持更弱備份場(chǎng)景下優(yōu)先選 NTFS。另一個(gè)大文件相關(guān)的報(bào)錯(cuò)是傳輸中途connection reset或broken pipe。Windows 端的網(wǎng)絡(luò)棧在高負(fù)載下偶爾會(huì)重置長(zhǎng)連接尤其是走無線網(wǎng)絡(luò)或者經(jīng)過某些中間設(shè)備時(shí)。緩解辦法是給 SSH 加心跳?；顓?shù)rsync -avz -e ssh -o ServerAliveInterval30 -o ServerAliveCountMax3 src/ userhost:dst/這樣連接空閑時(shí)每 30 秒發(fā)一次心跳連續(xù) 3 次無響應(yīng)才斷開能顯著降低長(zhǎng)傳輸被中間設(shè)備掐斷的概率。6.2 文件被占用導(dǎo)致的 Permission deniedWindows 上文件被程序打開時(shí)默認(rèn)是獨(dú)占鎖rsync 讀取會(huì)失敗報(bào)Permission denied或Read error。備份場(chǎng)景下最常撞上的是殺毒軟件實(shí)時(shí)掃描、索引服務(wù)、以及 Office 文檔的臨時(shí)鎖文件。排查時(shí)先看報(bào)錯(cuò)涉及的具體文件用資源監(jiān)視器resmon的CPU標(biāo)簽頁搜索句柄能定位到是哪個(gè)進(jìn)程占著。臨時(shí)方案是暫停殺毒軟件實(shí)時(shí)防護(hù)或者把備份目錄加入排除列表。長(zhǎng)期方案是調(diào)整備份時(shí)間窗口避開業(yè)務(wù)高峰期或者對(duì)確實(shí)無法避免的占用文件用--ignore-errors跳過但要接受這部分文件備份不完整的事實(shí)并在日志里標(biāo)記出來。6.3 殺毒軟件誤判 rsync 行為有些安全軟件會(huì)把 rsync 的高頻文件讀寫行為判定為可疑活動(dòng)直接攔截進(jìn)程或者隔離文件表現(xiàn)為 rsync 跑到一半突然退出日志里沒有任何有用信息。這種情況排查起來最費(fèi)勁因?yàn)閳?bào)錯(cuò)是沒有報(bào)錯(cuò)。判斷方法是臨時(shí)關(guān)閉安全軟件再跑一次如果正常了就把 rsync 可執(zhí)行文件和備份目錄加入白名單。企業(yè)環(huán)境下這個(gè)操作需要走審批提前和 IT 那邊溝通好。7. 一套可復(fù)用的排查流程與參數(shù)模板7.1 從報(bào)錯(cuò)到根因的四步定位法踩了這么多坑我總結(jié)出一套固定的排查順序能覆蓋 Windows 端 rsync 報(bào)錯(cuò)的九成場(chǎng)景先看路徑格式報(bào)錯(cuò)涉及路徑時(shí)第一時(shí)間確認(rèn)盤符前綴和斜杠方向是否符合當(dāng)前兼容層的規(guī)范。這一步能解決掉最多的文件明明存在卻找不到類問題。再砍參數(shù)把命令簡(jiǎn)化到最小可用集比如rsync -r src/ dst/跑通了再逐項(xiàng)加-l、-p、-t、-z。哪個(gè)參數(shù)加上去報(bào)錯(cuò)問題就鎖定在那個(gè)參數(shù)對(duì)應(yīng)的功能上。開詳細(xì)日志加-vv甚至--debugALL看 rsync 內(nèi)部到底在做什么。很多報(bào)錯(cuò)信息只是表象詳細(xì)日志里能看到真正的失敗點(diǎn)。隔離環(huán)境驗(yàn)證換一個(gè)兼容層比如從 cwRsync 換到 MSYS2或者換一臺(tái)機(jī)器跑同樣的命令能快速判斷是環(huán)境問題還是命令問題。這四步的順序是有講究的路徑問題最常見且最容易查放最前面參數(shù)裁剪能快速縮小范圍詳細(xì)日志用于兜底環(huán)境隔離用于確認(rèn)結(jié)論。按這個(gè)順序走大部分問題在第二步之前就能定位。7.2 Windows 端常用參數(shù)模板基于上面的經(jīng)驗(yàn)我整理了幾套在 Windows 上比較穩(wěn)的參數(shù)組合按場(chǎng)景區(qū)分場(chǎng)景推薦參數(shù)說明本地盤備份-rlt --delete --progress不碰權(quán)限保留時(shí)間和結(jié)構(gòu)刪除目標(biāo)端多余文件跨機(jī)同步走 SSH-rltz -e ssh -o ServerAliveInterval30壓縮傳輸加心跳保活含中文文件名同上外加--iconvUTF-8,GBK視環(huán)境編碼轉(zhuǎn)換按實(shí)際環(huán)境調(diào)整大文件續(xù)傳-rlt --partial --progress --inplace--inplace減少臨時(shí)文件開銷但中斷風(fēng)險(xiǎn)略高只同步不刪除-rlt --progress最保守的組合適合首次全量--delete要慎用Windows 端路徑寫錯(cuò)時(shí)它會(huì)把錯(cuò)誤目錄里的文件刪掉這個(gè)教訓(xùn)我見過不止一次。建議第一次跑帶--delete的命令時(shí)先加--dry-run確認(rèn)刪除列表符合預(yù)期再實(shí)跑。7.3 日志留存與失敗重試生產(chǎn)環(huán)境的同步任務(wù)務(wù)必把 rsync 的輸出重定向到日志文件加時(shí)間戳。Windows 批處理里可以這樣寫rsync -rlt --delete src/ dst/ D:\logs\rsync_%date:~0,4%%date:~5,2%%date:~8,2%.log 21失敗重試方面簡(jiǎn)單的做法是用批處理的if errorlevel判斷退出碼非零時(shí)等待一段時(shí)間重跑最多重試三次。退出碼含義0 成功23 部分文件傳輸失敗通常是權(quán)限或占用24 傳輸中源文件消失正?，F(xiàn)象文件在傳輸過程中被刪了其他碼基本是配置或連接問題。區(qū)分對(duì)待這幾種退出碼比無腦重試有效得多。8. 幾個(gè)容易被忽略的細(xì)節(jié)最后分享幾個(gè)實(shí)操中總結(jié)的小點(diǎn)都是文檔里不常寫但實(shí)際會(huì)遇到的。第一兼容層版本混用。機(jī)器上同時(shí)裝了 Git Bash、MSYS2、cwRsync 時(shí)PATH 里誰在前面rsync 命令就調(diào)誰而不同版本的 rsync 行為可能有細(xì)微差異。排查詭異問題時(shí)先用which rsync和rsync --version確認(rèn)當(dāng)前用的是哪個(gè)別在錯(cuò)誤的版本上浪費(fèi)時(shí)間。第二目標(biāo)目錄的父目錄必須存在。rsync 不會(huì)自動(dòng)創(chuàng)建多級(jí)父目錄dst/a/b/里如果dst/a不存在會(huì)報(bào)mkdir failed。腳本里提前用mkdir -p類命令建好目錄結(jié)構(gòu)能避免這類低級(jí)報(bào)錯(cuò)。第三-z壓縮不是萬能的。傳輸已經(jīng)壓縮過的文件圖片、視頻、zip時(shí)-z反而增加 CPU 開銷且?guī)缀醪皇挕＞钟蚓W(wǎng)內(nèi)傳輸大文件時(shí)去掉-z速度往往更快。這個(gè)參數(shù)要看場(chǎng)景不是默認(rèn)就該加。第四時(shí)間戳的時(shí)區(qū)問題。跨時(shí)區(qū)同步時(shí)-t保留的是源端時(shí)間戳的絕對(duì)值目標(biāo)端顯示的時(shí)間可能因?yàn)闀r(shí)區(qū)設(shè)置不同而看起來不對(duì)。這不是 bug是時(shí)區(qū)換算的正常表現(xiàn)別誤判成時(shí)間戳沒同步成功。這些細(xì)節(jié)單看都不起眼但組合在實(shí)際任務(wù)里往往就是那個(gè)讓你卡半天的點(diǎn)。Windows 端用 rsync心態(tài)上要接受它是個(gè)移植過來的工具遇到報(bào)錯(cuò)先想兼容層的翻譯環(huán)節(jié)順著這條線查比盲目搜報(bào)錯(cuò)原文靠譜得多。