大多數操作系統根本不管複製有沒有出錯，只管複製過程有沒有出錯。這中間是有區別的。得說細一些。
檢查複製沒出錯需要做複製校驗，這事是有幾個層次的。
最直觀的，也是成本最高的，就是把複製過去的東西再拿來讀一遍，和來源全部對照一遍。叫做全讀校驗。很顯然，這是一定能確認複製沒有錯的方法。然而它也很顯然太“貴”了，因為等於源數據要讀至少兩遍，拷貝數據要讀至少一遍寫至少一遍，相比不檢查多出了許多工作量。而且對很多應用場景來說，這甚至是做不到的。所以大多數操作系統默認不做這種程度的校驗。
為什麼很多場景下做不到？因為複製數據的場景比大多數人直觀想象要複雜得多，簡單直接順利的情景佔不到全部的九成。比如，最令人討厭情況有複製數據到慢速設備，寫入10Mbps讀取0.1Mbps，全讀校驗花的時間是複製本身的100倍。還有各種複製鎖無法保證的情況。例如源數據在校驗過程中改變了，或者你只有目標的寫權限沒有讀權限，或者你的來源數據只能讀一遍的情況。大量常見場景使得全讀校驗無法實現。
不用這種一定能確認複製沒錯的方法，還有什麼別的辦法嗎？那就分好幾種妥協方法了。
有些操作系統採用的妥協省事方法是hash校驗。複製的目標端有某種內置方法生成文件hash值，複製過程生成源數據的hash值，複製完成時對照一下兩個hash，一致就ok。這是一種比較聰明的低成本近似全讀校驗的辦法。這個方法顯然需要目標支持生成hash的方法，不然就得再讀一遍了，所以適用場景有限。
再弱一些，也就是Windows和大多數操作系統都支持的方法，就是管道可靠性校驗，也就是隻管複製過程有沒有出錯。思路是這樣的：我讀的時候要求讀數據管道確認讀沒出錯，寫的時候要求寫數據管道確認寫沒出錯，那基本的數據一致性就得到保證了。具體實現細節就不展開說了，情景其實也很複雜。只要知道這種校驗其實可以很弱，但總歸比沒有強太多。Windows用戶在複製文件時看到的CRC循環冗餘校驗錯誤實際上就是在寫管道上的校驗機制不能通過報的錯。這種方法也往往是所有其他更復雜校驗的基礎。
為什麼說這種校驗可以很弱呢？因為管道的可驗證性在很多常見條件下是很弱的。有時候甚至管道並沒有辦法去確認有沒有出錯。比如直到SATA年代硬盤的指令才有統一的校驗機制，在此之前很可能你讓硬盤寫數據你是無法判斷硬盤到底有沒有幹這事的。外加這個方法其實不能覆蓋端到端，因為讀出來的數據會停留在內存一段時間，而普通的內存是沒有數據一致性保護的。所以有少數運氣不好的用戶會發現內存損壞導致複製出現錯誤，而複製過程不報錯的現象。
大多數操作系統不管這事，錯了就錯了。
有些軟件本身會額外校驗，這算加了個保險。
某些文件系統本身就對數據塊有校驗，這算是在系統底層加了道保險（但這不是系統自己的功能），比如ZFS這樣的文件系統，每個數據塊都帶校驗，但這仍然屬於軟件層面的活，而不是磁盤扇區校驗這種硬件級的手段。
磁盤（或者其他存儲設備）在數據介質上都有額外編碼用於校驗或糾錯（以扇區為單位？），發現數據不對會嘗試重新讀取或者糾錯，如果多次嘗試後仍然失敗/操作超時/嚴重錯誤則會自行記錄（磁盤的S.M.A.R.T功能）並且提交到操作系統，告訴用戶“哥們，我盡力了，節哀順變吧”。
磁盤的數據從內部電路出來，要經過SATA或者其他接口，可能要再過PCI-E接口，途中可能還得在內存中留一份拷貝，完事可能還得從網絡接口出去……每一次接口通信都是一場冒險，天曉得數據會不會出錯，有時候會出點可以糾正的小錯誤，硬件失效/環境干擾則會出大錯（磁盤S.M.A.R.T裡有一項叫ECC錯誤，如果數值經常增大那說明SATA口或者SATA線有點毛病，不過這個過程本身是帶糾錯的，所以報錯不代表數據出錯）。
所以本著“早發現早治療”的原則，這些高速接口都帶驗證和糾錯，能改就改，不能改就丟棄重傳，實在不行就向上報錯。
所以，如果硬件可靠，那麼整個數據傳輸過程亦可靠，操作系統不會勞神費心做額外檢測。有些文件系統自帶數據分塊校驗的功能，這屬於特定軟件的特性。
如果硬件不靠譜，大多數錯誤都會被上報或者記錄下來，比如文件傳到一半停下來沒速度了，可能就是磁盤發現扇區讀到的數據校驗不通過，在嘗試重新讀取，如果很久都沒響應那這個扇區十有八九完蛋了，有時候磁盤 的控制電路出毛病了，往往會直接報IO錯誤。
但是有個硬件例外，錯了就是錯了，不報錯，等到發現不對一切都晚了，這就是普通內存（另外還有帶校驗的內存，算是加了道保險，服務器常用）。內存整個失效那就不多說了，如果顆粒內部數據位翻轉，這種事天知地知但你我不知，如果有機會這部分變形的數據還能被寫回磁盤蓋掉原始數據，這也是為什麼有些軟件和文件系統要額外加校驗的原因。
