1

I've recently been tinkering with deleting text files and seeing what information I can gather from the clusters that those files used to be on. However, I've hit something that's really made me scratch my head... DiskView is reporting that the first unallocated block (I like to call them clusters) on a FAT drive is on cluster 32269.

I've included this image which confirms that. I've included this image which confirms that. However, when I used WinHex to look at what information was left behind in cluster 32269, the program reported that it was occupied by a file that was on my disk.

This is what WinHex reports

This is what WinHex reports. Why does DiskView state this cluster is unoccupied, when WinHex thinks an actual "live" file (not deleted) is within the cluster? I scrolled down somewhat in WinHex, and according to that program the free space (its word for unallocated clusters) doesn't start until cluster 32273.

It's almost like the file on my disk is bleeding into 4 clusters it isn't supposed to be in, but I was under the impression that such a thing was impossible. Am I seriously misinterpreting these results, or is there something incredibly wrong here?

UPDATE: As requested, here's how WinHex displayed cluster 32273. I've also correlated WinHex displays between cluster 32270 - 32273. The bytes per cluster is 1,024 and the bytes per sector is 512. The LesMiserables1 file is what DiskView thinks should be ending at cluster 32268, with clusters 32269 and over being free space. As seen in the combined image, WinHex states it actually ends at 32270 and shows the tail end of its volume slack.

Tyrx
  • 11

0 Answers0