Geralmente, quando os editores salvam arquivos, eles excluem ou truncam para 0, liberando espaço alocado e, em seguida, escrevem, o que aloca novo espaço. Isso resulta no sistema de arquivos colocando os dados em um local físico completamente diferente. Portanto, sua ideia pode não funcionar.
Você pode obter o local físico de um arquivo usando filefrag
ou hdparm --fibmap
e, em seguida, use-o dd
para ler diretamente esse local físico. Descrevi esse processo em um contexto diferente aqui: /unix//a/85880/30851
No seu caso, é mais provável que você precise da abordagem geral para encontrar dados de texto ... algo como:
strings -n 12 -t d /dev/partition | grep -F 'text snippet'
strings
procurará dados ASCII consecutivos (também suporta outras codificações, não tem certeza sobre UTF-8. Se for código ou inglês, não será necessário) e também imprimirá o deslocamento onde foi encontrado.
text snippet
deve ser um exemplo de texto exato e exclusivo que você se lembra de estar na parte do arquivo que está procurando [em uma única linha]. (Se você não souber exatamente, poderá grep com expressões regulares.)
-n 12
é o comprimento mínimo que strings
você procurará. 12
deve ser o comprimento do seu text snippet
. Este parâmetro é opcional, se fornecido, pode ajudar strings | grep
a ir um pouco mais rápido.
Levará muito tempo para ler toda a partição, mas se for bem-sucedido, você terá um deslocamento para alimentar a dd
área geral e remover as coisas que não pertencem.
Eu não fiz nada nesse diretório desde
Se o seu diretório não for um ponto de montagem ... a maioria dos sistemas de arquivos não reserva espaço "por diretório", portanto ... toda e qualquer gravação em todo o sistema de arquivos pode sobrescrever o que você está procurando. Em uma situação de recuperação de dados, você geralmente muda a coisa inteira para o modo somente leitura.
strings
, apenas localizamos algumas partes do arquivo, a menos que você tenha muita sorte.