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ą filefrag
lub hdparm --fibmap
, a następnie użyć dd
do 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 snippet
powinien 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 12
to minimalna długość, której strings
będzie szukać. 12
powinna być długością twojego text snippet
. Ten parametr jest opcjonalny, jeśli podany może pomóc strings | grep
nieco 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ć, dd
aby 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.
strings
zlokalizuje tylko niektóre części pliku, chyba że masz ogromne szczęście.