當空間明顯足夠時，為什麼 xcopy 會失敗？
我有一個 2TB 硬碟驅動器“D”，在 2TB NTFS 分區上包含 732GB 的數據，我想將它（絕對是驅動器上的所有內容）複製到另一個具有 981GB 空間的驅動器“F”（它是新格式化的 (NTFS)）。
我確保沒有程序正在寫入磁碟 D 或 F。只有一個備份程序正在執行（backblaze），我假設它只執行讀取操作，所以應該沒問題。
我通過管理員提升的命令提示符開始複製：
C:\Users\Me\Desktop\: xcopy /x /o /h /e /k D: F:然後大約 20 小時後，命令失敗，說“空間不足”。我檢查了資源管理器，磁碟 F 確實 100% 滿了。D盤沒有增長或任何東西，仍然只有732GB在使用。
我在這裡一無所知。為什麼數據突然變大了？我應該嘗試使用諸如 clonezilla 之類的 live cd 嗎？
（附帶問題：我可以以某種方式加快這個過程嗎？）
更新 1
根據建議，我嘗試了以下方法：
robocopy D:\ F:\ /COPYALL /E /DCOPY:T /R:10 /LOG:copylog.log /XD .bzvol我排除
.bzvol了（只有 82 KB），因為如果我不這樣做，它會混淆反光！這導致一旦 F 已滿，就會“無休止地”重複此消息：
ERROR 112 (0x00000070): There is not enough space on the disk. Waiting 30 seconds...以下是一些視覺證據：
我檢查了驅動器 D未設置為“壓縮此驅動器以節省磁碟空間”。
驅動器 D由TrueCrypt 7.1a 加密。它目前在我複制時安裝。但這不應該是這裡的一個因素，我認為。
更新 2
根據新的回饋，我收集了兩個分區的一些統計數據。查爾的錢是對的。目標磁碟上的群集大小明顯更大。我想知道這兩者中的哪一個是兩者的“正確”（更好）設置，但是為了複製成功，我無論如何都沒有太多選擇。感謝大家的幫助。
源卷 D（實際上是 TrueCrypt 容器內的文件系統）和目標卷 F 上的集群大小（分配單元大小）是多少？
驅動器被填滿的一個假設是卷 F 具有較大的群大小，而卷 D 有許多小文件。這意味著相同的數據在目標卷 F 上可能會比在源卷 D 上佔用更多的空間。