删除 FAT32 USB 上的文件会更改第一个簇信息
我制作了一个文件恢复软件，它读取FAT32目录条目并识别文件的第一个簇并尝试恢复数据，它应该工作正常，但是当我尝试使用FAT32 USB磁盘时，会发生以下情况。
未删除文件时分配给文件的簇号与删除后立即分配给文件的簇号不同。 我使用 Disk Investigator 和 Tune Up Undelete 来验证这一点，但它们都无法恢复该文件。 常见的问题是，通常在删除文件名时，第一个字符会更改为 0xE5，其余部分保持不变，但这也会改变它的簇信息。
有什么帮助吗？ 您能尝试使用 FAT32 USB 并告诉我发生了什么吗？
我的操作系统是 Windows Vista，Pen Drive 是单分区 FAT32。
i have made a file recovery software, which reads the FAT32 directory entry and identifies the first cluster of the file and attempts to recover the data, it is supposedly to be working fine however when i try on a fat32 usb disk the following happens.
The Cluster number assigned to a file when it is not deleted is different from the cluster number, immediately after it is deleted. I used Disk Investigator and Tune Up Undelete to verify this, none of them w.ere able to recover the file. It was the common problem that, usually upon deleting the file's name first character is changed to 0xE5 and rest remains intact, but this is changing it's cluster information too.
Any help?
Can you try with your FAT32 USB and tell me what is happening?
My OS is Windows Vista, Pen Drive is Single Partition FAT32.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
也许 vista 真的有意更改目录项中的第一个簇字段？ 它实际上将其更改为什么呢？ 您没有发布任何带有真实数字的示例。 如果在每种情况下都用 0 或 0xFFFFFFFF 之类的数字覆盖该字段，则可以肯定地表明 Vista 正在故意破坏此信息，以便您找不到该文件。 如果它不必要地将该字段更改为其他有效的簇号，那就非常奇怪了。
您没有提到的另一件事是，文件的数据实际上是否仍然物理地位于其最初所在集群的磁盘上。 查看物理存储在旧位置和新位置（假设新值是确实存在的簇号）中的内容的实际扇区转储将会很有趣。 如果两个位置都没有实际的文件数据，您可以完整捕获所有扇区并进行搜索。 文件的原始数据是否仍然位于任何群集/扇区的驱动器上？
我知道这并不是一个很好的答案，但是由于信息太少（并且不太愿意实际安装 Vista 并尝试这些东西），这就是我所能做的。
Perhaps vista really is intentionally changing the first cluster field within the directory entry? What is it actually changing it to? You didn't post any examples with real numbers. If it's overwriting that field with some number like 0 or 0xFFFFFFFF in every case, that's a pretty sure sign Vista is intentionally destroying this information so you can't find the file. If it's changing that field, unnecessarily, to some other valid cluster number, well that's very strange.
Another thing you didn't mention is if the file's data is actually still physically on the disk in the cluster where it was originally located. Seeing actual sector dumps of what is physically stored in the old locations and new location (assuming the new value is a cluster number which really exists) would be interesting. If neither location has the actual file data, you could do a complete capture of all sectors and search. Is the file's original data even still on the drive in any cluster/sector at all?
I know this isn't much of an answer, but with so little information (and not much inclination to actually install Vista and try this stuff), this is about all I can do.
您可能会看到USB磨损均衡效果。
这篇关于测试 USB 记忆棒和数据恢复工具的建议< /strong>对此有更多注释。
更新：与我上面的假设相矛盾的参考。
最近有一篇关于闪存的取证潜力的论文，其中
这么说
磨损均衡在物理层面起作用，不会影响
逻辑层（软件访问）。
还没有读过这篇论文...但是，对于所有对闪存设备感兴趣的人来说，这似乎是很好的信息。
You are probably seeing the USB Wear Leveling effect.
This post on Advice for Testing USB sticks and Data recovery tools has more notes on this.
Update: Reference that contradicts my assumptions above.
There is a recent thesis on The forensic potential of flash memory which
says that
wear-leveling works at the physical level and does not impact the
logical level (software access).
Have not read this thesis yet... but, it seems to be good information for all interested in flash devices.
我在谷歌搜索同一问题时偶然发现了这个问题。 这个问题很老了，但我希望我的回答能有所帮助。
此问题与闪存问题无关。 当从 FAT32 分区中删除文件时，其第一个簇的高位字将被清零，简单明了（ https://www.cnwrecovery.com/html/fat32.html）。
因此，与 FAT12/FAT16 不同，无法直接恢复 FAT32 上已删除的文件（和目录）。
I've stumbled upon this question while googling the same issue. The question is old, but I hope my answer will help.
This problem has nothing to do with Flash memory issues. When a file is deleted from a FAT32 partition, its first cluster's high word is zeroed out, plain and simple (https://www.cnwrecovery.com/html/fat32.html).
It is thus impossible to straightforwardly recover deleted files (and directories) on FAT32, unlike FAT12/FAT16.
您可能想要将您编写的代码与“icat”和“fls”程序进行比较，这些程序是 SleuthKit（开源计算机取证工具包）的一部分。 使用 SleuthKit，您可以轻松找到已删除的 FAT32 文件的目录条目，然后查找 inode。 您可以在 http://sleuthkit.org/ 找到 SleuthKit
You probably want to compare the code that you have written to the "icat" and "fls" programs that are part of SleuthKit, the open source computer forensics toolkit. Using SleuthKit you can easily find the directory entries for deleted FAT32 files and then icat the inodes. You can find SleuthKit at http://sleuthkit.org/
简而言之：在闪存中，当写入一个块时，必须首先擦除该块周围的一组块，然后根据该块的更改重新写入。 因此，写入其邻居标记为未分配的块（尽管您稍后实际上需要该数据）可能会导致未分配的块被写入零。 或者，旧块可能被标记为未分配，并且可以将更改写入已经空白的簇中的新块，然后块更改将在某处记录下来。
此行为不是特定于操作系统的，而是实际上由 USB 设备本身处理。 因此，我们需要知道您使用的是哪种设备，除非您所说的是所有 USB 闪存设备上都会发生这种情况，而您的问题中对此并不清楚。
Anand Shimpi 在他现在著名的 SSD Anthology 文章（降解章节中的 EG）； 如果您喜欢这样的事情，甚至还有详细的跟进。
To put it shortly: in flash memory, when a block is written to, a cluster of blocks around that block must first be erased, then re-written with the changes to the block taken into account. Therefore, writing to a block whose neighbor is marked as unallocated (though you actually want that data later) might be causing the unallocated block to be written as zeros. Alternatively, the old block might be marked unallocated, and a new block in an already blank cluster could be written to with the changes, and then the block changes would get noted somewhere.
This behavior is not OS specific but actually handled by the USB device itself. We would therefore need to know what kind of device you're using, unless what you are saying is that this happens on all your USB flash devices, which wasn't clear in your question.
The long version is much better explained by Anand Shimpi in his now famous SSD Anthology article (E.G. in the degradation chapter); there's even a detailed follow up if you like that sort of thing.