直接打开word，应该能找到之前打开过的文件；
如果直接修改保存文件，通过电脑版再次打开时应该能看到保存的文件。
然而，你可以看不到最近访问过的文档；打开的文档也用；所以我觉得可能是文档修改后没有保存，也可能是你保存为，但是保存的文档可能已经被处理、删除或者移动了。
可以通过windows自带的搜索功能搜索一下，看看能不能找回。对于win10，点击桌面左下角的win按钮，输入文件名进行搜索。
大多数操作系统不支持。;idon'我不在乎复制过程中是否有错误，只在乎复制过程中是否有错误。这是有区别的。我们需要更加具体。
有几个关卡可以检查抄袭有没有错误。
最直观最费钱的就是把抄来的东西再读一遍，和出处对比。it这叫做全读检查。显然，这是一种确保复制没有问题的方法。但是，这显然太昂贵了，因为这意味着源数据至少要读取两次，复制的数据至少要读取一次，至少要写入一次，这意味着比不检查要多很多工作。而对于很多应用场景来说，这甚至是不可能的。因此，默认情况下，大多数操作系统不进行这种级别的验证。
为什么可以很多情况下不都是这样吗？因为复制数据的场景比大多数人直观想象的要复杂得多，简单、直接、流畅的场景占全部的不到90%。比如最烦的情况就是把数据拷贝到一个慢的设备上，写10mbps读0.1mbps，全读验证花费的时间是拷贝本身的100倍。还有各种不能保证复制锁的情况。例如，源数据在验证过程中发生了变化，或者您只有目标写权限而没有读权限，或者您的源数据只能被读取一次。大量常见的场景使得完全读取验证成为不可能。
没有这个方法还有没有其他方法可以确认文案是正确的？那么妥协的方法有几种。
一些操作系统使用散列检查作为折衷方法。有一个内置的方法可以在复制的目标端生成文件哈希值，源数据的哈希值是在复制过程中生成的。复制完成后，比较两个哈希，如果一致就ok了。这是一种智能且低成本的近似完全读取验证的方法。这种方法显然需要目标支持生成hash的方法，否则就要重新读取，所以应用场景有限。
windows和大多数操作系统都支持的一种较弱的方法是管道可靠性检查，即在复制过程中是否有任何错误。思路是这样的:读的时候让数据管道确认读的没有错，写的时候让数据管道确认写的没有错，这样就保证了基本的数据一致性。具体实现细节就不展开了。我说过，情况其实很复杂。只要知道这个检查其实可以很弱，总比没有强很多。windows用户在复制文件时看到的crc循环冗余校验错误，其实就是写管道上的校验机制无法通过报告的错误。这种方法通常是所有其他更复杂检查的基础。
为什么这个检查会很弱？因为在很多常见的情况下，管道的可验证性是很弱的。有时候连管道都没有办法确认是否有错误。比如，直到sata时代才有统一的硬盘指令验证机制。在此之前，很有可能你让硬盘写数据，你可以无法判断硬盘是否已经这样做了。另外，这种方法可以t其实是覆盖端到端的，因为读取的数据会在内存中停留一段时间，普通内存没有数据一致性保护。因此，少数不幸的用户会发现内存损坏导致复制出错，并且复制过程不会报告错误。
