我最近一直在尝试删除文本文件，看看我能从这些文件曾经所在的群集中收集到什么信息。然而，我遇到了一件让我头疼的事情……DiskView 报告说第一个未分配的块（我喜欢称它们为集群）在 FAT 驱动器上位于群集 32269 上。
我附上了这张图片来证实这一点。
然而，当我使用 WinHex 查看 32269 簇中留下的信息时，程序报告说它被我磁盘上的一个文件占用了。
WinHex 报告
为什么 DiskView 会说这个簇未被占用，而 WinHex 却认为实际“居住”文件（未删除）是否在群集内？我在 WinHex 中向下滚动了一些，根据该程序，可用空间（未分配群集的单词）直到群集 32273 才开始。
这几乎就像我磁盘上的文件流血的将其分成 4 个不应该属于的簇，但我认为这样的事情是不可能的。我是否严重误解了这些结果，或者这里有什么难以置信的错误？
更新：根据要求，WinHex 显示集群 32273 的方式如下。我还关联了WinHex 显示集群 32270 - 32273 之间。每簇字节数为 1,024，每扇区字节数为 512。LesMiserables1 文件是 DiskView想应该在簇 32268 处结束，簇 32269 及以上为可用空间。如组合图所示，WinHex 表示它实际上在 32270 处结束，并显示了其卷松弛的尾端。
