Leia o final do arquivo passado para recuperar dados


12

Um arquivo .swp muito antigo reverteu um arquivo que eu estava editando, por isso agora é significativamente mais curto. Como não fiz nada nesse diretório desde então, os bytes imediatamente após o final do arquivo ainda devem ter meus dados. Que função posso usar para ler N bytes de um determinado endereço de memória? dde readpare nos limites do arquivo, a menos que eu tenha perdido uma opção em algum lugar.

O tamanho atual do arquivo é 3,2 KB. Não me lembro exatamente do tamanho do arquivo antes de ser truncado, mas provavelmente não superior a 10 KB. Como posso ler 10 KB desde o início do arquivo, ignorando os limites do arquivo? Tudo bem se os dados não forem perfeitamente preservados, desde que eu não precise começar do zero.

Respostas:


18

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 filefragou hdparm --fibmape, em seguida, use-o ddpara 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 snippetdeve 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 stringsvocê procurará. 12deve ser o comprimento do seu text snippet. Este parâmetro é opcional, se fornecido, pode ajudar strings | grepa 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.


Observe que cada arquivo é armazenado em vários blocos e geralmente não são armazenados consecutivamente. Portanto strings, apenas localizamos algumas partes do arquivo, a menos que você tenha muita sorte.
Gilles 'SO- stop be evil'

3
Muito pelo contrário, você teria que ser extremamente azarado para encontrar um arquivo fragmentado de 10 KB. Se você encontrar apenas uma peça, é mais provável que a outra peça tenha sido substituída nesse caso. Mas, a menos que você tenha muita atividade de gravação nesse sistema de arquivos ou seja um SSD com descarte instantâneo, se você salvou o arquivo várias vezes durante a edição, poderá encontrar muitas cópias desse arquivo.
Frostschutz 31/10

3
Eu recomendaria strings -n16ou um comprimento mínimo razoável, para torná-lo mais rápido.
27568 Peter

Bom ponto, acrescentou à resposta.
Frostschutz

4
Muitíssimo obrigado. Havia apenas lixo logo após o final do arquivo, mas stringsconsegui encontrar o arquivo inteiro em outro local da partição. São quase dois meses de trabalho que não preciso repetir, e um excelente lembrete para sempre usar o controle de versão para qualquer coisa importante.
Matthew Bedford
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.