Gdzie idą pliki po wydaniu polecenia rm?


98

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?


3
oto możliwy duplikat. cofnij na Linuksie . Ale nie jestem do końca pewien, czy pliki są zupełnie inne niż te, które można cofnąć.
ksenoterracid

Odpowiedzi:


120

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.


4
Bardzo dziękuję za jasne wyjaśnienie. Nie mam nic przeciwko korzystaniu z CLI, po prostu muszę być nieco bardziej ostrożny, używając symboli wieloznacznych. :)
boehj

16
Byłbym ostrożny przy użyciu czegoś takiego jak libtrashzmiana zachowania rm. Wiele skryptów używa rmdo czyszczenia plików, a nie chcesz, aby były wyświetlane w Koszu. Polecam użycie dedykowanego polecenia, takiego jak trashz trash-clipakietu. @pedro Powinienem dodać, że kiedyś utworzyłem plik * w moim katalogu domowym. Przez przypadek zacytowałem *, kiedy nie powinienem go tworzyć, więc postanowiłem go usunąć za pomocą rm * naturalnie. Kiedy zdałem sobie sprawę z tego, co zrobiłem, szybko zabiłem polecenie, ale już usunęło kilka plików z mojego katalogu domowego.
penguin359

4
Rzadko zdarza się mieć coś w rodzaju kosza na śmieci w powłoce, więc jeśli dodasz go do lokalnego komputera i przyzwyczaisz się do niego, a nawet będziesz na nim polegał w codziennej pracy. Możesz wpaść w kłopoty, korzystając z innych 99% uniksów: bez jednego ...
Johan

3
Myślę, że przesłanie „do domu” jest takie, że muszę przestać CLI'ing we wczesnych godzinach i zwracać większą uwagę.
boehj

2
W tym samym wierszu, co powiedział @Johan, RedHat zwykł (nadal robi?) Ustawiać aliasy dla poleceń takich jak cpi mv, do cp -ii mv -ipodczas działania jako root. Zmienia to domyślne zachowanie, więc te polecenia zawsze będą pytać przed zastąpieniem istniejących plików. Niektórzy administratorzy zalecali specjalne usunięcie tych aliasów, abyś nie spodziewał się, że takie zachowanie może być śmiertelne w innym systemie, który zachowuje się domyślnie.
penguin359

11

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ę ...).


2
W przypadku danych tekstowych o wysokiej wartości zawsze możesz użyć dowolnego solidnego narzędzia ogólnego przeznaczenia (nawet emacsa lub perla), aby spojrzeć na „surowe urządzenie” dysku zawierającego usunięty plik i wyszukać znane ciągi; W ten sposób odzyskałem dokumenty Worda dla ludzi; tracą narzut, ale mogą odzyskać większość tekstu. Oczywiście jest to odzyskiwanie po awarii, a nie „Cofnij”.
Alexis

Właściwy link „ręcznie”: web.archive.org/web/20131221183925/http://…
sjas

8

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)


Jest to nieco bardziej skomplikowane, np. Przez zerowanie zerowania wskaźników blokujących w i-węźle, ale tak, wyszukiwanie plików może bezpośrednio działać - jeśli są wystarczająco małe lub przydzielone w ciągłym bloku. Jest to czasami nazywane rzeźbieniem plików i istnieją narzędzia, magicrescuektóre próbują znaleźć obrazy lub dźwięki według ich charakterystycznych wzorów.
Piskvor,

6

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


... chyba że plik jest wyraźnie oznaczony chattr +satrybutem („niszczenie”). Mówi systemowi plików, aby specjalnie nadpisał ten plik zerami podczas usuwania. Tylko niektóre systemy plików będą obsługiwały ten atrybut.
telcoM

3

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ą.


0

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


4
Działa to tylko wtedy, gdy masz jakiś magiczny system plików, który zapewnia tę funkcję (np. NetApp) lub jeśli używasz specjalnej wersji rm.
mattdm
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.