Zazwyczaj, gdy redaktorzy zapisują pliki, usuwają lub obcinają do 0, uwalniając w ten sposób przydzielone miejsce, a następnie zapisują, co przydziela nowe miejsce. Powoduje to, że system plików umieszcza dane w zupełnie innej fizycznej lokalizacji. Twój pomysł może więc nie działać.
Możesz uzyskać fizyczną lokalizację pliku za pomocą filefraglub hdparm --fibmap, a następnie użyć dddo bezpośredniego odczytania tej fizycznej lokalizacji. Opisałem ten proces w innym kontekście tutaj: /unix//a/85880/30851
W twoim przypadku bardziej prawdopodobne jest, że potrzebujesz ogólnego podejścia do wyszukiwania danych tekstowych ... coś takiego:
strings -n 12 -t d /dev/partition | grep -F 'text snippet'
strings będzie szukał kolejnych danych ASCII (obsługuje również inne kodowania, nie jestem pewien co do UTF-8. Jeśli jest to kod lub angielski, nie będziesz go potrzebować), a także wydrukuje przesunięcie tam, gdzie zostało znalezione.
text snippetpowinien być dokładną, unikalną próbką tekstową, o której pamiętasz, że znajdujesz się w części pliku, którego szukasz [w jednym wierszu]. (Jeśli nie znasz tego dokładnie, możesz zamiast tego skorzystać z wyrażeń regularnych).
-n 12to minimalna długość, której stringsbędzie szukać. 12powinna być długością twojego text snippet. Ten parametr jest opcjonalny, jeśli podany może pomóc strings | grepnieco szybciej.
Odczytywanie całej partycji zajmie dużo czasu, ale jeśli się powiedzie, będziesz mieć przesunięcie, które możesz przesłać, ddaby złapać ogólny obszar, a następnie usunąć rzeczy, które nie należą.
Od tamtej pory nic nie zrobiłem w tym katalogu
Jeśli twój katalog nie jest punktem montowania ... większość systemów plików tak naprawdę nie rezerwuje miejsca „na katalog”, więc ... wszystkie zapisy w całym systemie plików mogą zastąpić szukany bit. W sytuacji odzyskiwania danych zwykle przełączasz całą funkcję w tryb tylko do odczytu.
stringszlokalizuje tylko niektóre części pliku, chyba że masz ogromne szczęście.