DiskView reporta cluster não alocado, mas o WinHex relata o cluster ocupado por arquivo de disco - por quê?

Question

Recentemente, comecei a mexer na exclusão de arquivos de texto e ver as informações que posso coletar dos clusters em que esses arquivos costumavam estar. No entanto, eu bati em algo que realmente me fez coçar a cabeça ... DiskView está relatando que o primeiro bloco não alocado (eu gosto de chamá-los de clusters) em uma unidade FAT está no cluster 32269.

Eu incluí esta imagem que confirma isso. Noentanto,quandoeuuseioWinHexparaverquaisinformaçõesforamdeixadasparatrásnocluster32269,oprogramarelatouqueeleestavaocupadoporumarquivoqueestavanomeudisco.

IssoéoqueoWinHexreporta

Por que o DiskView declara que esse cluster está desocupado, quando o WinHex pensa em um arquivo "live" real (não excluído) está dentro do cluster? Rolei um pouco para baixo no WinHex e, de acordo com esse programa, o espaço livre (sua palavra para clusters não alocados) não é iniciado até o cluster 32273.

É quase como se o arquivo em meu disco estivesse sangrando em 4 clusters nos quais ele não deveria estar, mas eu estava com a impressão de que tal coisa era impossível. Eu estou seriamente interpretando mal esses resultados, ou há algo incrivelmente errado aqui?

UPDATE: conforme solicitado, aqui está como o WinHex exibiu o cluster 32273 . Eu também correlacionei o WinHex é exibido entre o cluster 32270 - 32273 . Os bytes por cluster são 1.024 e os bytes por setor são 512. O arquivo LesMiserables1 é o que o DiskView acha que deve terminar no cluster 32268, com clusters 32269 e sendo espaço livre. Como visto na imagem combinada, o WinHex afirma que, na verdade, termina em 32270 e mostra o final de sua folga de volume.