Gdzie idą pliki po wydaniu polecenia rm?

Niedawno przypadkowo zrobiłem to rmna zestawie plików i pomyślałem, gdzie dokładnie te pliki się kończą?

Oznacza to, że podczas pracy z GUI usunięte pliki trafiają do Kosza. Co jest równoważne rmi czy istnieje sposób cofnięcia rmpolecenia?

Nigdzie nie ma, zniknął. A dokładniej, plik zostaje odłączony. Dane nadal znajdują się na dysku, ale łącze do nich zostało usunięte. Kiedyś możliwe było odzyskiwanie danych, ale obecnie metadane są usuwane i nic nie można odzyskać.

Nie ma kosza na śmieci rm, ani nie powinno być. Jeśli potrzebujesz Kosza, powinieneś użyć interfejsu wyższego poziomu. W trash-cliUbuntu znajduje się narzędzie wiersza poleceń , ale przez większość czasu menedżery plików GUI, takie jak Nautilus lub Dolphin, są używane do zapewnienia standardowego kosza na śmieci. Kosz jest sam w sobie standardem. Pliki przechowywane w Dolphin będą widoczne w Koszu z Nautilusa.

Pliki są zwykle przenoszone do miejsca, w ~/.local/share/Trash/files/którym są usuwane. rmPoleceń w systemie UNIX / Linux jest porównywalna delna DOS / Windows, który także usuwa ani nie przenoś plików do Kosza. Inną rzeczą do zrealizowania jest to, że przenoszenie pliku między systemami plików, takimi jak dysk USB z dysku twardego, to tak naprawdę 1) kopia danych pliku, a następnie 2) odłączenie oryginalnego pliku. Nie chcesz, aby Twój Kosz był wypełniony tymi dodatkowymi kopiami.

Ext3 / ext4 za, można spróbować odzyskać pliki przy użyciu narzędzi takich jak extundelete lub ext3grep , lub nawet iść brudząc ze strukturami niskopoziomowych ręcznie (nie dla osób o słabym sercu); w przypadku wielu systemów plików możesz spróbować wyszukać jeszcze nie nadpisane bloki według określonych wzorców (np. magicrescue może wyszukiwać między innymi nagłówki JPEG). Pamiętaj, że używają heurystyki do odzyskiwania plików z pozostawionych metadanych, więc pełne odzyskanie nie jest gwarantowane - jest to raczej zakład ostatniej szansy (ponieważ wymagają one, aby niektóre ślady plików pozostały w dzienniku i że bloki nie zostały jeszcze nadpisane).

Tak więc, dla wszystkich celów i celów, pliki usunięte za pomocą rmzniknęły - możesz wypróbować taką nekromancję, jaką oferują te narzędzia, ale nie polegaj na tym: są to narzędzia do wypróbowania, gdy wszystko inne zawiedzie. Lepiej wykopuj swoje ostatnie kopie zapasowe (tworzysz kopie zapasowe, prawda? No cóż, żyj i ucz się ...).

Odnośnie cofnięcia skutków rm:

Biorąc pod uwagę, że większość systemów plików usuwa tylko odniesienia do danych i wskazuje, że bloki są wolne, możesz spróbować zlokalizować odczyt danych bezpośrednio z urządzenia. Przy odrobinie szczęścia bloki zawierające twoje pliki nie zostały zgłoszone do czegoś innego.

Zakłada się, że masz coś wyjątkowego do wyszukania, które masz rootw systemie, i zgaduję, że łączenie wszystkiego, co obejmuje więcej niż jeden blok systemu plików (prawdopodobnie 4k), może skończyć się dość pracochłonnym, jeśli system plików nie poradzi sobie umieścić plik (i) w ciągłych blokach.

Udało mi się odzyskać zawartość kilku plików tekstowych, uruchamiając ciągi na urządzeniu, na którym był system plików, i grepszukając czegoś z tych plików o dużym kontekście ( -C). (Wkrótce po tym incydencie firma postanowiła przeznaczyć trochę zasobów na wdrożenie kopii zapasowych)

Za każdym razem, gdy usuwasz plik za pomocą rmpolecenia, dane pliku nigdy nie są usuwane. Innymi słowy, bloki w systemie plików zawierające dane wciąż tam są.

Po uruchomieniu rmpolecenia system oznacza i-węzeł należący do tego pliku jako nieużywany, a bloki danych tego pliku również jako nieużywane (ale nie usunięte). Jednak ext3zeruje większość pól w i-węźle, gdy plik jest usuwany.

To normalne zaznaczenie nieużywanego jest wykonywane dla prędkości ... W przeciwnym razie usunięcie zajmie trochę więcej czasu. Właśnie dlatego zauważyłeś, że usuwanie nawet dużych plików jest szybsze (możesz odzyskać dane, jeśli te bloki danych nie zostaną zastąpione).

Więcej informacji: Struktura i-węzła , Jak działa usuwanie pliku

W systemach plików w stylu uniksowym (w tym w systemie Linux) pliki nie są tak naprawdę „w” żadnym konkretnym miejscu. Zamiast tego system używa twardych dowiązań, aby wskazywać na fragmenty, które stanowią dużą kroplę danych. Tworząc plik, tworzysz również jego pierwszy link stały: ten, który faktycznie znajduje się w miejscu, w którym „zapisałeś” plik. Jeśli utworzysz więcej dowiązań twardych, to o ile system wie, plik faktycznie istnieje w kilku miejscach jednocześnie.

Gdy „usuwasz” plik, zwykle usuwasz tylko łącze twarde, które istniało w określonym miejscu. Dlatego wywoływane jest wywołanie systemowe w celu usunięcia plików unlink(). System nie usunie pliku, dopóki nie pozostaną żadne łącza do niego. Ale kiedy ten ostatni link twardy zostanie zniszczony, dane też zostaną zniszczone.

Gdzie więc idą usuwane pliki? Jeśli nadal istnieją dowiązania twarde, pliki są tam, gdzie są dowiązania, których nie usunąłeś. Jeśli nie ma już żadnych linków, pliki znikają.

Zajrzyj również do ~ / .snapshot, jeśli plik został niedawno usunięty.