FileSystem FAT – File Allocation Table

Quando o Sistema de Arquivos FAT foi criado, lá pelos idos anos de 1980 os arquivos eram bem pequenos, ele cabia todinho em um Cluster, e raramente era particionado, talvez por isto o FAT foi pensado. O sistema hoje não é utilizado no Disco Rígido por exemplo, mas está em uso nos Pendrives.

Mas quando os armazenamentos ficaram grandes, tudo ficou bem angustiante, um arquivo grande é gravado de forma contígua , e não continua, ou seja, seus pedaços são espalhados pelo disco, no começo, no fim, no meio, de novo no fim, etc … até terminar.

Bem diferente do Sistema de Arquivo EXT que é utilizado no Linux,o ext não apaga seus mapas de alocação ( como faz o FAT ), quando um mapa de alocação tem seu arquivo correspondente apagado, ele não é todo zerado como no FAT, o Sistema de Arquivos EXT simplesmente desliga um Bit de um BitMap, cada bit corresponde a um INODE (cluster no caso do FAT), então o sistema sabe que o arquivo foi apagado mas pode restaurar todos seus mapas, bastando ligar o bit do BitMap e ele tem todo mapa de alocação disponível, essencial para montar as partes bagunçadas no Disco.

No caso do FAT, todo mapa de alocação é apagado, então não é possível recuperar arquivos grandes, já que seu mapa foi deletado para avisar o istema que aquele espaço esta disponível para futura gravação, pouco prático realmente.

No sistema NTFS , a coisa ficou bem mais interessante, ele otimiza tanto que arquivos muito pequenos nem são alocados longe da Entrada FILE, se temos somente uma frase, ele grava aquela pequena frase já perto da configuração do arquivo, e não aponta para sua localização em um Cluster qualquer, já que iria onerar o espaço, não tem sentido abrir um espaço de 8 k para gravar uma frase de 10 letras.

Bem, mas nosso FAT não tem estas otimizações, ele é direto ! apagou o arquivo, apaga os mapas para avisar que aquele espaço está disponível, só deixando mesmo seu nome sem a primeira letra no Folder de gravação, avisando que foi apagado.

O sistema FAT é composto das seguintes partes:

1- BOOT (Master Boot Record) no caso de sistema inicializável

2- Depois vem o primeiro mapa do FAT (FAT 1 )

3- Após o fim do Fat 1, vem o Fat 2 que é uma cópia fiel, e útil para recuperar crash de sistema.

4- Após o Fat 1 , Fat 2 , vem a parte de ROOT (Raiz da unidade).

5- Depois da Raiz vem a área de gravação de dados, e a maior da unidade.

No exemplo acima, vemos o F8 FF FF 0F indicado o primeiro cluster, e logo no circulo vernelho o fim do mapeamento do arquivo no FAt1.

Logo após vem o FAT2 que é igualzinho o FAT1, então logo após o FAT2, vem o ROOT ( Raiz )

Neste comecinho do ROOT ( setor Raiz ) no endereço 800000 , vemos 2 arquivos gravados , o DEBUG32.EXE e um apagado chamado EDIT.COM, perceba que a primeira letra está com um “a” acentuado, que corresponde ao codigo E5, indicado que o arquivo EDIT.COM foi apagado.

E é só isto mesmo, ao apagar o arquivo ele muda a primeira letra com o codigo E5 e apaga todo seu mapa do Fat.

A coisa tudo é assim mesmo, não esquecendo que na frente do nome do arquivo, tem a indicação do primeiro Cluster do arquivo que será gravado o começo, as partes restantes serao lidas mais tarde. ( nem tão mais tarde assim )

Um Exemplo:

Abaixo no exemplo, vemos o arquivo DEBUG.EXE alocando varios cluster, começando pelo cluster 00 00 00 03 até cluster 00 00 00 19h nos 4 bytes corrspondente ao cluster 3 vemos o numero 04 00 00 00 que indica o pulo para o proximo cluster 4 e assim vai até o cluster 19h que nao aponta para nenhum outro, o FF FF FF 0Fh indica fim de ocupação de cluster.

Após apagar o arquivo DEBUG.EXE, o ssitema coloca o código E5h no lugar de “D” de Debug, indicado que o arquivo foi apagado, e seu espaço correspondente no mapeamento de FAT é ZERADO ! olhe la na ponta da flexa vermelha, tem só zeros onde tinha números antes, e este é todo problema do FAT, como recuperar se o mapeamento foi todo zerado ? tal problemas nao ocorre no sistema EXT nem NTFS.