O que realmente aconteceu em um nível de bits e bytes é que 4 bytes (ou mais) da tabela de alocação de arquivos foram sobrescritos com 0x00 bytes.
Vou explicar resumidamente como funciona a tabela de alocação de arquivos. Pode ser visto como um array cujos valores são índices desse mesmo array. Portanto, se soubermos que o primeiro número de cluster de um arquivo é i , o próximo número de cluster será fat[i] e o próximo depois será fat[fat[i]] , e assim por diante. (Isso é um pouco simplificado). Para sinalizar que o final da cadeia é alcançado, um valor EOC especial é usado em vez de um número de cluster válido.
Para ler um arquivo FAT do disco, você precisa dos números de cluster onde o arquivo está armazenado, em ordem. A entrada de diretório fornece o primeiro número de cluster ( i ). O resto pode ser encontrado seguindo a corrente fat[i] , fat[fat[i]] etc. até que o valor EOC seja encontrado. Então, é um cálculo simples para obter a posição em disco de cada cluster dos números do cluster, ler cada cluster na memória e concatená-los.
O erro fat_get_cluster: invalid cluster chain ocorre quando o valor 0x00000000 é encontrado seguindo tal cadeia. Isso não deveria acontecer. Deve ser um novo número de cluster válido ou o valor EOC. Não é mais possível ler o arquivo quando isso acontece, pois não há como acompanhar a cadeia ainda mais. (O valor 0x00000000 é usado para marcar um cluster como livre. O cluster 0 nunca é usado para armazenar dados, portanto não há ambigüidade)
Seu caso pode ser um caso especial, já que i_pos é dado como 0. Quando recebi esta mensagem, era um número grande. Fonte do kernel diz:
loff_t i_pos; /* on-disk position of directory entry or 0 */
Portanto, i_pos não é um número de cluster, mas uma posição no disco. O que significa quando é zero, eu não sei.
EDIT: Quanto ao que pode ter causado isso, só posso especular, mas aqui estão algumas possibilidades:
- Um erro de driver FAT.
- Raios cósmicos .
- Um vírus ou outro software malicioso .
- Talvez se dois programas / pilotos estivessem escrevendo e lendo para o mesmo FAT simultaneamente por algum motivo, eles poderiam atropelar um ao outro. Não sei se é possível.
- Desligue-o no momento errado. As unidades flash precisam zerar um bloco antes de gravar alterações, portanto, teoricamente, um desligamento logo após o apagamento causaria esse resultado. No entanto, existem failsafes para evitar isso na maioria das unidades.
- Erro do usuário ou sabotagem (por exemplo,
dd if=/dev/zero of=/dev/sda1 bs=512 count=1 seek=32- não tente fazer isso em casa!)
Os drivers do sistema de arquivos FAT na verdade mantêm duas tabelas FAT atualizadas para redundância, enquanto a segunda está logo após a primeira . Verificar se eles são idênticos pode dar pistas do que pode ter acontecido. Se eles diferissem apenas no valor que quebra a cadeia de clusters, eu acho que a manipulação direta de alguma forma é mais provável, já que pelo menos 1 e 3 devem fazer o trabalho "adequadamente".
Parece-me provável, porém, que a maioria dos drivers modernos manteria toda a tabela FAT na RAM e escreveria as partes que retornam às duas cópias na unidade. Assim, mesmo se houvesse uma diferença, ela poderia ter sido rápida e silenciosamente "consertada" durante o uso normal. Note que este é apenas um palpite.
No final, é muito difícil saber com alguma certeza sem maiores informações sobre as circunstâncias, e mesmo assim é provável que haja adivinhações. Circunstâncias ideais seriam se você pudesse recriar de forma confiável o problema. Então, eu compararia as tabelas FAT "antes" e "depois" (e os cabeçalhos FAT) para ver exatamente o que havia sido alterado e o que, procurando por sugestões na localização e no conteúdo das alterações.