微信文件復(fù)制后在何處找到？直接打開word，應(yīng)該能找到之前打開過的文件；如果直接修改保存文件，通過電腦版再次打開時應(yīng)該能看到保存的文件。然而，你可以 看不到最近訪問過的文檔；打開的文檔也用；所以我覺得

微信文件復(fù)制后在何處找到？

直接打開word，應(yīng)該能找到之前打開過的文件；

如果直接修改保存文件，通過電腦版再次打開時應(yīng)該能看到保存的文件。

然而，你可以 看不到最近訪問過的文檔；打開的文檔也用；所以我覺得可能是文檔修改后沒有保存，也可能是你保存為，但是保存的文檔可能已經(jīng)被處理、刪除或者移動了。

可以通過Windows自帶的搜索功能搜索一下，看看能不能找回。對于win10，點擊桌面左下角的win按鈕，輸入文件名進(jìn)行搜索。

怎么辨別文件是不是復(fù)制的？

大多數(shù)操作系統(tǒng)不支持。;I don'我不在乎復(fù)制過程中是否有錯誤，只在乎復(fù)制過程中是否有錯誤。這是有區(qū)別的。我們需要更加具體。

有幾個關(guān)卡可以檢查抄襲有沒有錯誤。

最直觀最費錢的就是把抄來的東西再讀一遍，和出處對比。It 這叫做全讀檢查。顯然，這是一種確保復(fù)制沒有問題的方法。但是，這顯然太昂貴了，因為這意味著源數(shù)據(jù)至少要讀取兩次，復(fù)制的數(shù)據(jù)至少要讀取一次，至少要寫入一次，這意味著比不檢查要多很多工作。而對于很多應(yīng)用場景來說，這甚至是不可能的。因此，默認(rèn)情況下，大多數(shù)操作系統(tǒng)不進(jìn)行這種級別的驗證。

為什么可以 很多情況下不都是這樣嗎？因為復(fù)制數(shù)據(jù)的場景比大多數(shù)人直觀想象的要復(fù)雜得多，簡單、直接、流暢的場景占全部的不到90%。比如最煩的情況就是把數(shù)據(jù)拷貝到一個慢的設(shè)備上，寫10Mbps讀0.1Mbps，全讀驗證花費的時間是拷貝本身的100倍。還有各種不能保證復(fù)制鎖的情況。例如，源數(shù)據(jù)在驗證過程中發(fā)生了變化，或者您只有目標(biāo)寫權(quán)限而沒有讀權(quán)限，或者您的源數(shù)據(jù)只能被讀取一次。大量常見的場景使得完全讀取驗證成為不可能。

沒有這個方法還有沒有其他方法可以確認(rèn)文案是正確的？那么妥協(xié)的方法有幾種。

一些操作系統(tǒng)使用散列檢查作為折衷方法。有一個內(nèi)置的方法可以在復(fù)制的目標(biāo)端生成文件哈希值，源數(shù)據(jù)的哈希值是在復(fù)制過程中生成的。復(fù)制完成后，比較兩個哈希，如果一致就ok了。這是一種智能且低成本的近似完全讀取驗證的方法。這種方法顯然需要目標(biāo)支持生成hash的方法，否則就要重新讀取，所以應(yīng)用場景有限。

Windows和大多數(shù)操作系統(tǒng)都支持的一種較弱的方法是管道可靠性檢查，即在復(fù)制過程中是否有任何錯誤。思路是這樣的:讀的時候讓數(shù)據(jù)管道確認(rèn)讀的沒有錯，寫的時候讓數(shù)據(jù)管道確認(rèn)寫的沒有錯，這樣就保證了基本的數(shù)據(jù)一致性。具體實現(xiàn)細(xì)節(jié)就不展開了。我說過，情況其實很復(fù)雜。只要知道這個檢查其實可以很弱，總比沒有強(qiáng)很多。Windows用戶在復(fù)制文件時看到的CRC循環(huán)冗余校驗錯誤，其實就是寫管道上的校驗機(jī)制無法通過報告的錯誤。這種方法通常是所有其他更復(fù)雜檢查的基礎(chǔ)。

為什么這個檢查會很弱？因為在很多常見的情況下，管道的可驗證性是很弱的。有時候連管道都沒有辦法確認(rèn)是否有錯誤。比如，直到SATA時代才有統(tǒng)一的硬盤指令驗證機(jī)制。在此之前，很有可能你讓硬盤寫數(shù)據(jù)，你可以 無法判斷硬盤是否已經(jīng)這樣做了。另外，這種方法可以 t其實是覆蓋端到端的，因為讀取的數(shù)據(jù)會在內(nèi)存中停留一段時間，普通內(nèi)存沒有數(shù)據(jù)一致性保護(hù)。因此，少數(shù)不幸的用戶會發(fā)現(xiàn)內(nèi)存損壞導(dǎo)致復(fù)制出錯，并且復(fù)制過程不會報告錯誤。