Do czego służy folder lost + found w systemach Linux i Unix?

644

W katalogu głównym systemów operacyjnych Linux i Unix znajduje się folder o nazwie /lost+found/

Po co to jest? W jakich okolicznościach miałbym z tym kontakt? Jak miałbym z tym współdziałać?

filesystems directory-structure lost-found

— Wesley
źródło

Zauważ, że używają tylko ext2 (oraz ext3 i ext4) lost+found. Jeśli chcesz go ukryć, użyj innego systemu plików lub zamontuj go gdzie indziej, przechowuj wszystko w podkatalogu i dowiązaj podkatalog do „prawdziwego” miejsca, z którego korzystasz z danych.

— Adam Katz

@Gilles ktoś był na tyle uprzejmy, aby go dodać: en.wikipedia.org/wiki/Fsck#Use

— David Kennedy

Zauważ, że lost+foundjest to specyficzne dla rozszerzonego systemu plików Linux (ext2–4). Unices, np. FreeBSD zazwyczaj nie mają tego katalogu w swoich systemach plików (UFS, ZFS).

— FUZxxl,

Przykro nam, ale lost+foundpraktycznie zawsze istnieje na systemach BSD. W rzeczywistości właśnie sprawdziłem i na pewno było tam na 4.3BSD i wydaje mi się, że pamiętam to dużo wcześniej. I z pewnością jest dzisiaj na FreeBSD.

— Bob Eager

@BobEager Dziękujemy za potwierdzenie. Też tak myślałem, ale byłem gotów zaakceptować, że może źle zapamiętałem ...

— Pryftan

Odpowiedzi:

577

Po uruchomieniu fsckpolecenia sprawdzania i naprawy systemu plików może znaleźć fragmenty danych, do których nie ma odniesienia w żadnym miejscu w systemie plików. W szczególności fsckmoże znaleźć dane, które wyglądają jak kompletny plik, ale nie mają nazwy w systemie - i- węzła bez odpowiedniej nazwy pliku. Te dane wciąż zajmują miejsce, ale nie są dostępne w żaden normalny sposób.

Jeśli powiesz, fsckaby naprawić system plików, zamieni te prawie usunięte pliki z powrotem w pliki. Rzecz w tym, że plik miał kiedyś nazwę i lokalizację, ale ta informacja nie jest już dostępna. Więc fsckdeponuje plik w określonym katalogu o nazwie lost+found(po zagubionej i znalezionej własności).

Pliki, które się pojawiają, lost+foundto zazwyczaj pliki, które zostały już rozłączone (tj. Ich nazwa została usunięta), ale nadal zostały otwarte przez jakiś proces (więc dane nie zostały jeszcze usunięte), gdy system nagle się zatrzymał (panika jądra lub awaria zasilania). Jeśli to wszystko się wydarzyło, te pliki i tak zostały przeznaczone do usunięcia, nie musisz się tym przejmować.

Pliki mogą się również pojawiać, lost+foundponieważ system plików był niespójny z powodu błędu oprogramowania lub sprzętu. W takim przypadku możesz znaleźć pliki, które zostały utracone, ale naprawa systemu zdołała je uratować. Pliki mogą zawierać przydatne dane, ale nawet jeśli są, mogą być niekompletne lub nieaktualne; wszystko zależy od stopnia uszkodzenia systemu plików.

W wielu systemach plików lost+foundkatalog jest nieco wyjątkowy, ponieważ wstępnie przydziela trochę miejsca na fsckumieszczanie tam plików. (Miejsce nie jest na dane pliku, które fsckpozostają na miejscu; są to pozycje katalogu, które fsckmuszą uzupełnić.) Jeśli przypadkowo usuniesz lost+found, nie twórz go ponownie mkdir, użyj, mklost+foundjeśli jest dostępny.

— Gilles
źródło

Ponadto, jeśli przypadkowo usunięty fsck może go ponownie utworzyć następnym razem, gdy znajdzie system plików w czystości (co prawdopodobnie będzie następnym uruchomieniem).

— derobert

Czy ten folder powinien być od czasu do czasu sprawdzany i czyszczony?

— TheLQ,

@TheLQ Tylko wtedy, gdy twój system plików doznał znacznego uszkodzenia, fsckbył wymagany i wspomniał o wyszukiwaniu plików i łączeniu ich lost+found. Przez 20 lat z różnymi systemami plików widziałem to tylko raz. I to było zanim dziennik był normą.

— Alexios

Myślę też, że jeśli pojawi się sformatować HDD (przeszedłem z NTFS na ext4 i wyglądał)

— PUK

@puk lost+foundKatalog jest tworzony za każdym razem, gdy tworzysz system plików ext4 (jak w przypadku wielu innych systemów plików), niezależnie od tego, czy odbywa się to w ramach instalacji systemu, czy nie. „Sformatuj dysk twardy” to tylko jeden z takich przypadków. W fscktym przypadku możliwe jest dodanie tam plików.

— Gilles,

lost+foundKatalogu (nie lost + found) jest konstruktem wykorzystywane przez fsckkiedy nie jest uszkodzenie systemu plików (nie do urządzenia sprzętowego, ale do FS). Pliki, które normalnie zostałyby utracone z powodu uszkodzenia katalogu, zostałyby połączone w lost+foundkatalogu tego systemu plików według numeru i-węzła. Niektóre z nich mogą zostać utracone katalogi lub utracone pliki, a nawet utracone urządzenia. Każdy system plików powinien mieć własny lost+foundkatalog, ale możesz patrzeć na system z tylko jednym systemem plików. Ogólnie rzecz biorąc, powinieneś mieć nadzieję, że katalog jest pusty; ale w przypadku korupcji bądź wdzięczny, że w wielu warunkach pliki można odzyskać po fsckumieszczeniu ich tutaj.

— Arcege
źródło

Ważna uwaga: te i tak mogą stać się dość uciążliwe. Na przykład, gdy próbujesz wykonać findoperację na jednej lub wielu ext[2|3|4]partycjach z konta użytkownika innego niż administrator, zawsze otrzymasz te całkowicie niepotrzebne błędy „odmowy uprawnień” . Oczywiście istnieją sposoby na obejście tego rodzaju błędów - ale jest to trochę niewygodne, ponieważ standard find . -name '*whatever*'nie załatwi sprawy.

— syntaxerror

@syntaxerror: Miło słyszeć, jak mówisz o irytacji find: `./lost+found ': Odmowa dostępu . Od czasu do czasu mnie też to wkurza ...

— Johan E

@syntaxerror powód, dla którego doszedłem do tego pytania, było właśnie dlatego, że robiłem operację znajdowania i znajdowałem generowanie Permission deniedostrzeżenia. Biorąc pod uwagę odpowiedź na to pytanie, wiem, że lost+foundjest to część systemu plików, więc mogę bezpiecznie zignorować wygenerowane ostrzeżenie (ale szkoda, że nie wygenerowało ostrzeżenia).

— Trevor Boyd Smith

@JohanE Mówisz mi. Jednak rzeczywisty powód dlaczego ja pisał mój komentarz był ponieważ ta odpowiedź próbował sugerować nam „wdzięczny” za lost+found. To było zbyt zabawne, aby mogło być prawdziwe (siedziałem tutaj z szerokim uśmiechem), ponieważ śmiesznie kilka razy, kiedy jesteśmy wdzięczni za to, że nie może konkurować z tymi, gdy wolelibyśmy rzucić „Begone!” przeliteruj to uciążliwe lo + fo rzecz.

— składnia błąd

Z „Hierarchii systemu plików Linux”, sekcja / lost + found ” :

Jak wyjaśniono wcześniej podczas przeglądu FSSTND, Linux powinien zawsze przechodzić prawidłowe zamknięcie. Czasami system może ulec awarii lub awaria zasilania może spowodować wyłączenie urządzenia. Tak czy inaczej, przy następnym uruchomieniu zostanie przeprowadzona długa kontrola systemu plików za pomocą fsck. Fsck przejdzie przez system i spróbuje odzyskać wszystkie znalezione uszkodzone pliki. Wynik tej operacji odzyskiwania zostanie umieszczony w tym katalogu. Odzyskane pliki prawdopodobnie nie będą kompletne ani sensowne, ale zawsze istnieje szansa na odzyskanie czegoś wartościowego. Każda partycja ma własny katalog lost + found. Jeśli znajdziesz tam pliki, spróbuj przenieść je z powrotem do pierwotnej lokalizacji. Jeśli znajdziesz coś w rodzaju zepsutego dowiązania symbolicznego do „pliku”, musisz ponownie zainstalować plik / pliki z odpowiedniego RPM, ponieważ twój system plików został tak poważnie uszkodzony, że pliki zostały okaleczone nie do poznania. Poniżej znajduje się przykład katalogu / lost + found. Jak widać, ogromna większość zawartych tu plików to tak naprawdę gniazda. Jeśli chodzi o pozostałe pliki, okazało się, że są to uszkodzone pliki systemowe i osobiste. Tych plików nie można odzyskać.

— Bhupal
źródło