一个文件夹 （不是当我运行 Sublime Text 应用程序时，闪存驱动器中包含杂项的文件（即磁盘本身）变成了单个USBC[]ÇNY文件。它没有修改日期，什么都没有，看起来像是损坏了，文件管理器显示它的大小为 3.42 GB 和 0 GB。
我现在的问题是能发生了什么？我使用磁盘检查 ( dskchk) 和 Recuva 之类的工具，但什么都没有得到。我得到的最好的结果是，多亏了dskchk，破坏了那个文件，但它只有一个USBC...标题，其中大部分内容为空，只有 32 KB。，这意味着它什么都没有！我至少怎样才能避免这种情况发生？
在尝试dskchkRecuva 之前，我使用 WinRaR 打开 USBC 文件，它说文件不存在。我也尝试重命名它，但它仍然不存在。只有命令提示符找到它：
而且，该_Self文件夹只是一个ascargo文件夹。该ascargo文件夹在 Sublime Text（工作区）中打开，所以这可能是问题所在？
现在我怀疑我是否真的可以恢复内容，但幸运的是这只是一个实验......我想知道这是怎么发生的。
答案1
我多次见过这种情况，多年来一直在寻找解决方案。我想我现在找到了一个。如果你真的看看 USBC 扇区，你会发现你可以将其解码为 USB 命令块。而且这些扇区会导致后续扇区发生移动。哦，这不是病毒，也与任何病毒无关。
下面是我的一个例子，它因多个原因而很有趣，我将在稍后解释：
两件事情：
我们看到了 USBC 扇区和 NTFS 引导扇区。如果我们解码 NTFS 引导扇区，您会发现它“认为”自己位于 LBA 63，而实际上它位于 LBA 64。
USBC 扇区可以解码为 USB 命令块！
就我而言，它会解码为类似“从 LBA 63 开始写入 16 个扇区”的内容（2Ah 是写入命令）。
因此，我的分析是，由于某种原因（真的不知道）USB 命令块最终被写入驱动器，但更重要的是，它将数据“移动”一个 LBA 扇区。因此，USBC 扇区被插入，而不是覆盖扇区。
在同一个驱动器上，我发现了其他几个“USBC”扇区，它们都导致了扇区偏移。如果这些扇区出现在可见的位置，比如在我示例中非常靠近引导扇区的位置，或者在 OP 示例中我们实际上注意到的目录中的位置。但是，这些扇区也可能出现在用户数据中（我们只能通过在十六进制编辑器中打开文件才能发现它）或者可能出现在未分配的磁盘空间中。我猜 USBC 案例（有时被认为是病毒的结果，我们可以在互联网上找到）可能只是冰山一角。也许一些被认为无法恢复的案例实际上是由这个问题引起的。
这些偏移会产生影响，具体取决于它们发生的位置，因为在文件系统中，数据是通过簇号而不是某个偏移量来寻址的。这解释了文件系统失败的原因，也解释了文件恢复软件失败的原因。两者失败的原因完全相同。为了正确寻址簇，我们需要考虑这些偏移：
n = 当前簇之前插入的 USBC 扇区数。fs_ofs = 文件系统偏移量（LBA 地址）cl_factor = 每个簇的扇区数
Cluster 到 LBA 的转换应该是 LBA = fs_ofs + (cluster * cl_factor) + n
我发现处理该问题的一种更简单的方法是对驱动器进行映像处理并直接跳过所有“USBC 扇区”。这样做的好处是，所有能够处理 dd 类型磁盘映像的文件恢复软件都可用于恢复数据。