Normalmente, quando os editores salvam arquivos, eles excluem ou truncam para 0, liberando assim o espaço alocado e, em seguida, escrevem, o que aloca o novo espaço. Isso resulta no sistema de arquivos colocando os dados em um local físico completamente diferente. Então, sua ideia pode não funcionar.
Você pode obter o local físico de um arquivo usando filefrag ou hdparm --fibmap e, em seguida, usar dd para ler esse local físico diretamente. Eu descrevi este processo em um contexto diferente aqui: link
No seu caso, é mais provável que você precise da abordagem geral para encontrar dados textuais ... algo como:
strings -n 12 -t d /dev/partition | grep -F 'text snippet'
strings irá procurar por dados ASCII consecutivos (também suporta algumas outras codificações, não tem certeza sobre UTF-8. Se é código ou inglês você não precisará) e também irá imprimir o offset onde foi encontrado.
text snippet deve ser uma amostra de texto exata e única que você lembra estar na parte do arquivo que está procurando [em uma única linha]. (Se você não sabe exatamente, você pode usar expressões regulares).
-n 12 é o tamanho mínimo que strings irá procurar. 12 deve ser o tamanho do seu text snippet . Esse parâmetro é opcional, se fornecido, pode ajudar strings | grep a ir um pouco mais rápido.
Demorará muito tempo para ler a partição inteira, mas, se obtiver êxito, você terá um deslocamento que poderá alimentar dd para capturar a área geral e, em seguida, remover itens que não pertencem.
I haven't done anything in that directory since
Se o seu diretório não for um ponto de montagem ... a maioria dos sistemas de arquivos realmente não reservam espaço "por diretório", então ... toda e qualquer escrita em todo o sistema de arquivos pode sobrescrever o bit que você está procurando . Em uma situação de recuperação de dados, você geralmente alterna tudo para o modo somente leitura.