Plik jest tajemniczo pusty. Opcje do odzyskania?

Widziałem kilka postów na temat odzyskiwania usuniętych plików, ale ta sytuacja jest inna. Moja żona miała plik o nazwie Journal.odt, w którym przechowywała wiele ważnych danych osobowych, takich jak specjalne wspomnienia o naszych dzieciach. Innego dnia, gdy próbowała otworzyć go w OpenOffice, narzekał na format. Kazałem jej uderzyć anulować i wycofać się. Kiedy I catplik jest całkowicie pusty. lsmówi, że plik ma 0 bajtów.

Gdyby przypadkowo wybrała cały tekst w pliku, nacisnęła backspace i zapisała go, w pliku nadal byłyby meta informacje OpenOffice.

Natychmiast wyłączam jej laptop, aby zapobiec wprowadzaniu jakichkolwiek zmian na dysku, dopóki nie wymyślę czegoś do zrobienia.

W przeszłości robiłem kilka skomplikowanych rzeczy, takich jak ddodzyskiwanie surowego tekstu z dysku, ale nie mam pojęcia, co tutaj zrobić. Ponieważ pliki ODT nie są zwykłym tekstem, nie mogę po prostu przesłać całego dysku przez grep.

Wszelkie sugestie będą mile widziane.

Również jeśli ktoś ma wgląd w to, co mogło pójść nie tak, chętnie to usłyszę.

Dzięki

Jeśli używasz systemu plików ext3, spróbuj wykonać HOWTO Carlo Wooda

W kilku słowach

• Użyj ext3grep $ IMAGE --ls --inode 2 | grep twój_plik, aby znaleźć plik, którego szukasz (gdzie $ IMAGE to twoja partycja, na przykład / dev / sda2)
• Znajdź blok systemu plików zawierający dziennik nieprzydzielonego miejsca.
• Znajdź wszystkie deskryptory dziennika odnoszące się do bloku, które znaleziono wcześniej.
• Skopiuj blok za pomocą dd.
• Edytuj plik, aby usunąć końcowe zera.
• cat plik gdziekolwiek chcesz

Ze źródła:

„Rozdział Ręczny przykład odzyskiwania

W poniższym przykładzie ręcznie odzyskamy mały plik. Podano tylko częściowe dane wyjściowe, aby zaoszczędzić miejsce i uczynić przykład bardziej czytelnym.

Używając ext3grep $ IMAGE --ls --inode znajdujemy nazwę pliku, który chcemy odzyskać:

$ ext3grep $ IMAGE --ls --inode 2 | grep carlo 3 end d 195457 D 1202352103 czw 7 lutego 03:41:43 2008 drwxr-xr-x carlo

$ ext3grep $ IMAGE --ls --inode 195457 | grep 'bin $' | głowa -n 1 34 35 d 309540 D 1202352104 czw 7 lutego 03:41:44 2008 drwxr-xr-x bin

$ ext3grep $ IMAGE --ls --inode 309540 | grep start_azureus 9 10 r 309631 D 1202351093 czw 7 lutego 03:24:53 2008 rrwxr-xr-x start_azureus

Oczywiście, i-węzeł 309631 jest usuwany i nie mamy numerów bloków dla tego pliku:

$ ext3grep $ IMAGE --print --inode 309631 [...] I-węzeł jest nieprzydzielony Grupa: 19 Identyfikator generacji: 2771183319 uid / gid: 1000/1000 tryb: rrwxr-xr-x rozmiar: 0 liczba linków: 0 sektorów: 0 (-> 0 bloków pośrednich).

Czas i-węzła: Dostęp: 1202350961 = Czw 7 lutego 03:22:41 2008 Zmodyfikowano plik: 1202351093 = Czw 7 lutego 03:24:53 2008 Zmieniono i-węzeł: 1202351093 = Czw 7 lutego 03:24:53 2008 Czas usuwania: 1202351093 = Czw 7 lutego 03:24:53 2008

Bloki bezpośrednie:

Dlatego postaramy się poszukać starszej kopii w czasopiśmie. Najpierw znajdujemy blok systemu plików zawierający ten i-węzeł:

$ ext3grep $ IMAGE --inode-to-block 309631 | grep rezyduje Inode 309631 rezyduje w bloku 622598 z przesunięciem 0xf00.

Następnie znajdujemy wszystkie deskryptory dziennika odnoszące się do bloku 622598:

$ ext3grep $ IMAGE --journal --block 622598 [...] Deskryptory dzienników odnoszące się do bloku 622598: 4381294 26582 4381311 28693 4381313 28809 4381314 28814 4381321 29308 4381348 30676 4381349 30986 4381350 31299 4381374 1497 4381374 32986 4382137 6672 4382138 7536 4382139 7984 4382140 8931

Oznacza to, że transakcja o numerze sekwencji 4381294 ma kopię bloku 622598 w bloku 26582 i tak dalej. Największy numer sekwencji na dole powinien być ostatnimi danymi zapisanymi na dysku, a zatem blok 8931 powinien być taki sam jak bieżący blok 622598. Aby znaleźć ostatnią nieusuniętą kopię, należy zacząć od dołu i pracować w górę.

Jeśli spróbujesz wydrukować taki blok, ext3grep rozpozna, że ​​jest to blok z tabeli i-węzłów i wydrukuje zawartość wszystkich 32 i-węzłów w nim. Chcemy jednak zobaczyć i-węzeł 309631; więc używamy smart grep:

$ ext3grep $ IMAGE --print --block 8931 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- Identyfikator generacji: 2771183319 uid / gid: 1000/1000 tryb: rrwxr-xr-x rozmiar: 0 liczba linków: 0 sektorów: 0 (-> 0 bloków pośrednich).

Czas i-węzła: Dostęp: 1202350961 = Czw 7 lutego 03:22:41 2008 Zmodyfikowano plik: 1202351093 = Czw 7 lutego 03:24:53 2008 Zmieniono i-węzeł: 1202351093 = Czw 7 lutego 03:24:53 2008 Czas usuwania: 1202351093 = Czw 7 lutego 03:24:53 2008

Bloki bezpośrednie:

Jest to rzeczywiście to samo, co widzieliśmy w bloku 622598. Następnie patrzymy na mniejsze numery sekwencji, aż znajdziemy jeden z czasem usuwania 0. Pierwszym, który znajdujemy (od dołu do góry) jest blok 6073:

$ ext3grep $ IMAGE --print --block 6073 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- Identyfikator generacji: 2771183319 uid / gid: 1000/1000 tryb: rrwxr-xr-x rozmiar: 40 liczba linków: 1 sektory: 8 (-> 0 bloków pośrednich).

Czas i-węzła: Dostęp: 1202350961 = Czw. 7 03:22:41 2008 Zmodyfikowano plik: 1189688692 = Czw 13 15:04:52 2007 I-węzeł Zmodyfikowano: 1189688692 = Czw 13 września 15:04:52 2007 Czas usuwania: 0

Bloki bezpośrednie: 645627

Powyższe jest zautomatyzowane i można to zrobić znacznie szybciej dzięki opcji wiersza poleceń --show-journal-inodes. Ta opcja znajdzie blok, do którego należy i-węzeł, a następnie znajdzie wszystkie kopie tego bloku w dzienniku, a następnie drukuje tylko żądane i-węzły z każdego z tych bloków (z których każdy zawiera 32 i-węzły, jak wiadomo), eliminując duplikaty :

$ ext3grep $ IMAGE --show-journal-inodes 309631 Liczba grup: 75 Minimalny / maksymalny blok dziennika: 1115/35026 Ładowanie deskryptorów dziennika ... gotowe Transakcja dziennika 4381435 owija się, niektóre bloki danych mogły zostać utracone z tej transakcji. Liczba deskryptorów w czasopiśmie: 30258; min / max numery sekwencji: 4379495/4382264 Kopie i-węzła 309631 znalezione w czasopiśmie:

-------------- I-węzeł 309631 ----------------------- Identyfikator generacji: 2771183319 uid / gid: 1000/1000 tryb: rrwxr-xr-x rozmiar: 0 liczba linków: 0 sektorów: 0 (-> 0 bloków pośrednich).

Czas i-węzła: Dostęp: 1202350961 = Czw 7 lutego 03:22:41 2008 Zmodyfikowano plik: 1202351093 = Czw 7 lutego 03:24:53 2008 Zmieniono i-węzeł: 1202351093 = Czw 7 lutego 03:24:53 2008 Czas usuwania: 1202351093 = Czw 7 lutego 03:24:53 2008

Bloki bezpośrednie:

-------------- I-węzeł 309631 ----------------------- Identyfikator generacji: 2771183319 uid / gid: 1000/1000 tryb: rrwxr-xr-x rozmiar: 40 liczba linków: 1 sektory: 8 (-> 0 bloków pośrednich).

Czas i-węzła: Dostęp: 1202350961 = Czw. 7 03:22:41 2008 Zmodyfikowano plik: 1189688692 = Czw 13 15:04:52 2007 I-węzeł Zmodyfikowano: 1189688692 = Czw 13 września 15:04:52 2007 Czas usuwania: 0

Bloki bezpośrednie: 645627

Plik jest naprawdę mały: tylko jeden blok. Kopiujemy ten blok za pomocą dd, jak pokazano wcześniej:

$ dd if = $ OBRAZ bs = 4096 liczba = 1 pominięcie = 645627 = blok 645627 1 + 0 zapisów w 1 + 0 zapisanych 4096 bajtów (4,1 kB) skopiowanych, 0,0166104 sekund, 247 kB / s

a następnie edytuj plik, aby usunąć końcowe zera, lub skopiuj pierwsze 40 bajtów (podany rozmiar pliku):

$ dd if = block.645627 bs = 1 count = 40 of = start_azureus 40 + 0 rekordów w 40 + 0 rekordów na 40 bajtów (40 B) skopiowanych, 0,000105397 sekund, 380 kB / s

$ cat start_azureus cd / usr / src / azureus / azureus ./azureus &

Odzyskany!"

Wypróbuj testdisk i photorec , ale rozumiem, że twoje pisanie jest prawdopodobnie trudnym sposobem na poznanie wartości regularnych kopii zapasowych. Możesz także chcieć uruchomić komputer z dysku CD, aby zapobiec dalszej zmianie dysku twardego. Osobiście podoba mi się w tym celu System Rescue Disk , ale jest on w dużej mierze oparty na linii poleceń.

Użyj Caine, specjalnej dystrybucji linuksa dla cyfrowej medycyny sądowej. To mnóstwo narzędzi do odzyskiwania plików i dysku twardego.