遇上一個偶發錯誤,問題雖小(而且要很雖小才會遇到吧)也很快被修正,但細思極恐,令人發毛。

Windows 遠端桌面連線(Remote Desktop)的跨機複製貼上功能相信大家都有用過,你可以在本機複製文字、圖片,甚至檔案,在遠端主機按 Ctrl-V 或透過滑鼠右鍵選單貼上,達到跨主機傳遞資料的目標。(如果失效,可以試試這棵葱或檢查是否被封鎖)

複製貼上功能用了多年,靠它搬檔無數,今天接到報案,遠端主機上某支 ASPX 檔案出現詭異錯誤,說不認得 ASP 內建控制項的 BoundColumn.HeaderStyle 屬性。ASPX 在本機測試沒問題,丟上遠端主機卻壞掉,SOP 第一步是確認遠端主機與本機的檔案相同,先排除丟錯版本、放錯位置之類的低級錯誤。一查之下,發現駭人事實,遠端主機上的檔案是壞的(下圖左邊是來源程式、右邊是遠端主機上的檔案),在 HeaderS 後方被插入了一長串 ASCII 0 字元,檔案末端則有另一長串 ASCII 0,錯亂檔案被多塞了 2,853 Bytes (8,701-5,848) 個 ASCII 0:

詢問當事人,檔案是用本機複製、遠端桌面貼上方式放上去的,將問題檔備份存查,用同樣操作再複製貼上一次,這次的內容就是正確的。

登楞! 所以,遠端桌面貼上檔案時有可能被隨機加料,這也太恐怖了吧!! 有可能某次貼上檔案時檔案就壞了,以為檔案被妥善保存,到幾個月或幾年後才發現,豈不崩潰?

當最基本的複製檔案動作都無法被信任,感覺世界都要崩壞了啊啊啊啊~

不過,遠端桌面複製貼上功能用了那麼久,遇過檔案太大傳輸失敗,檔案複製成功但內容錯亂是史上第一次(黑天鵝?);而這個功能全世界每天都有人用,若真有這類嚴重 Bug,應該早就爆出來了才對,究竟是哪個環節出錯,由於問題無法重現,我也無法斷定。

爬了文章,歷史上還真有網友回報過類似問題:

案例並不普遍,其中甚至被塞入 ASCII 0 導致檔案變大的狀況也跟我遇到的類似,但集中在 XP 時代,當時也有出了修正,不足以斷定跟我遇到的問題相同。

但爬文過程倒是看到另一則對用 RDP 傳檔的忠實建議

RDP 這個傳輸協定並不適合傳送檔案,過程檔案內容封包跟 UI 畫面、滑鼠操作封包在同一個管道傳送,很容易彼此干擾,誤判逾時而中斷重連,這是傳輸大檔很容易失敗的原因。建議改用 \\TSCLIENT\DRIVE_NAME 方式分享傳輸檔案。

而在 XPS 案例討論中,微軟的人也建議用 \\TSCLIENT\DRIVE_NAME 傳輸檔案。

【結論】

  1. 遇上了遠端桌面複製貼上檔案被加料的狀況,網路雖有相似案例,但為 XP 時代的 Bug,無法推論關連性
  2. 遠端桌面傳檔建議改用 \\TSCLIENT\DRIVE_NAME 保平安
    資安提醒:分享本機磁碟機給遠端桌面前請確認主機環境是安全的,否則遠端惡意程式有可能竊取、竄改或加密勒索本機檔案。


Comments

# by Swing

RDP確實會發生被加長串ASCII 0,幾Kb的檔案會變成幾Mb。 如果只是小檔案壓zip就好,貼到目的地,如果zip不能解壓縮就是被加料了。

Post a comment