Какова цель папки lost + found в Linux и Unix?


642

В корне операционных систем Linux и Unix есть папка, которая называется /lost+found/

Для чего это? При каких обстоятельствах я буду взаимодействовать с ним? Как бы я с этим взаимодействовал?


Обратите внимание, что используются только ext2 (и ext3 и ext4) lost+found. Если вы хотите спрятать его, либо используйте другую файловую систему, либо смонтируйте ее в другом месте, храните все в подкаталоге и вставьте в подкаталог символическую ссылку в «реальное» место, из которого вы используете данные.
Адам Кац

4
@ Жиль, кто-то был достаточно любезен, чтобы добавить это: en.wikipedia.org/wiki/Fsck#Use
Дэвид Кеннеди,

Обратите внимание, что lost+foundэто характерно для расширенной файловой системы Linux (ext2–4). Unices, например FreeBSD, обычно не имеют этого каталога в своих файловых системах (UFS, ZFS).
FUZxxl

5
Извините, но lost+foundпрактически всегда был на системах BSD. На самом деле, я только что проверил, и он определенно был там на 4.3BSD, и я, кажется, вспомнил это намного раньше. И это, безусловно, на FreeBSD сегодня.
Боб

@BobEager Спасибо, что подтвердили это. Я тоже так думал, но я был готов признать, что, может быть, я вспомнил неправильно ...
Прифтан

Ответы:


575

Если вы запустите fsckкоманду проверки и восстановления файловой системы, она может найти фрагменты данных, на которые нет ссылок нигде в файловой системе. В частности, fsckмогут быть найдены данные, которые выглядят как полный файл, но не имеют имени в системе - индекс без соответствующего имени файла. Эти данные все еще занимают место, но они не доступны никаким обычным способом.

Если вы скажете fsckвосстановить файловую систему, он превратит эти почти удаленные файлы обратно в файлы. Дело в том, что файл имел имя и местоположение один раз, но эта информация больше недоступна. Таким образом, fsckфайл помещается в определенный каталог, называемый lost+found(после утерянного и найденного свойства).

Файлы, которые появляются, lost+foundкак правило, являются файлами, которые уже были не связаны (то есть их имя было стерто), но все еще открыты каким-либо процессом (поэтому данные еще не были стерты), когда система внезапно остановилась (паника ядра или сбой питания). Если это все, что произошло, эти файлы все равно должны быть удалены, вам не нужно заботиться о них.

Файлы также могут появляться, lost+foundпотому что файловая система находилась в несогласованном состоянии из-за программной или аппаратной ошибки. Если это так, то вы можете найти файлы, которые были потеряны, но восстановление системы удалось спасти. Файлы могут содержать или не содержать полезные данные, и даже если они есть, они могут быть неполными или устаревшими; все зависит от того, насколько серьезным был ущерб файловой системе.

Во многих файловых системах lost+foundкаталог немного особенный, потому что он предварительно выделяет немного места для fsckразмещения файлов там. (Пространство не для данных файла, которые остаются на fsckместе; это для записей каталога, которые fsckдолжны быть заполнены.) Если вы случайно удалили lost+found, не создавайте его заново mkdir, используйте, mklost+foundесли доступно.


16
Кроме того, если случайно удаленный fsck может воссоздать его в следующий раз, он обнаружит, что файловая система чистая (что, вероятно, будет следующей загрузкой).
Дероберт

30
Эта папка должна время от времени проверяться и очищаться?
TheLQ

9
@TheLQ Только в том случае, если ваша файловая система сильно пострадала, fsckтребовалось найти файлы и связать их с ними lost+found. За 20 лет с различными файловыми системами я видел это только один раз. И это было до того, как журналирование стало нормой.
Алексиос

6
Я думаю, что это также появляется, если вы форматируете свой жесткий диск (я переключился с NTFS на ext4, и он появился)
puk

6
@puk lost+foundКаталог создается всякий раз, когда вы создаете файловую систему ext4 (как и во многих других файловых системах), независимо от того, выполняется ли она как часть установки системы или нет. «Форматировать жесткий диск» - это только один из примеров. Что fsckвозможно, чтобы добавить файлы там.
Жиль

64

lost+foundКаталог (не Проиграл + Found) представляет собой конструкцию , используется , fsckкогда есть повреждения файловой системы (не в аппаратное устройство, но к фс). Файлы, которые обычно теряются из-за повреждения каталога, будут связаны в lost+foundкаталоге этой файловой системы по номеру inode. Некоторые из них могут быть потерянными каталогами или потерянными файлами или даже потерянными устройствами. Каждая файловая система должна иметь свой собственный lost+foundкаталог, но вы, возможно, просматриваете систему только с одной файловой системой. В общем, вы должны надеяться, что каталог пуст; но если есть повреждение, будьте благодарны, что во многих случаях файлы могут быть восстановлены после того, как fsckони были размещены здесь.


4
Однако, верная точка зрения: в любом случае они МОГУТ стать довольно неприятными. Например, при попытке выполнить findоперацию на одном или нескольких ext[2|3|4]разделах из учетной записи пользователя, не являющегося администратором, вы всегда будете получать эти совершенно ненужные ошибки «отказано в разрешении» . Конечно, есть способы обойти такие ошибки - но это немного неловко, потому что стандарт find . -name '*whatever*'не сработает.
синтаксическая ошибка

2
@syntaxerror: Рад слышать, что вы говорите о неприятностях с find: `./lost+found ': В доступе отказано . Меня это тоже время от времени беспокоит ...
Йохан Е

1
@syntaxerror, причина, по которой я пришел к этому вопросу, была именно потому, что я выполнял операцию поиска, а команда find продолжала генерировать Permission deniedпредупреждение. Учитывая ответ на этот вопрос, я знаю, что lost+foundэто часть файловой системы, и поэтому я могу спокойно игнорировать сгенерированное предупреждение (но я бы хотел, чтобы оно не выдало предупреждение).
Тревор Бойд Смит

1
@JohanE Вы говорите мне. Однако фактическая причина, по которой я разместил свой комментарий, заключалась в том, что этот ответ пытался предложить нам «быть благодарным» за lost+found. Это казалось слишком смешным, чтобы быть правдой (я сидел здесь с широкой улыбкой), потому что смешно несколько раз, когда мы благодарны за то, что он не может конкурировать с теми, когда мы предпочли бы сыграть «Беги!» заклинание к этой неприятной вещи.
синтаксическая ошибка

36

Из раздела «Иерархия файловых систем Linux», раздел / lost + found » :

Как было объяснено ранее во время обзора FSSTND, Linux всегда должен проходить надлежащее завершение работы. Иногда ваша система может зависнуть или сбой питания может привести к поломке машины. В любом случае, при следующей загрузке будет выполнена длительная проверка файловой системы с использованием fsck. Fsck пройдет через систему и попытается восстановить любые найденные поврежденные файлы. Результат этой операции восстановления будет помещен в этот каталог. Восстановленные файлы вряд ли будут полными или имеют много смысла, но всегда есть вероятность, что что-то стоящее будет восстановлено. Каждый раздел имеет свой собственный каталог lost + found. Если вы найдете там файлы, попробуйте переместить их обратно в исходное местоположение. Если вы обнаружите что-то вроде неработающей символической ссылки на «файл», вам придется переустановить файл / файлы с соответствующего RPM, поскольку ваша файловая система была повреждена настолько сильно, что файлы были изуродованы до неузнаваемости. Ниже приведен пример каталога / lost + found. Как вы можете видеть, подавляющее большинство файлов, содержащихся здесь, на самом деле являются сокетами. Что касается остальных файлов, то были обнаружены поврежденные системные файлы и личные файлы. Эти файлы не удалось восстановить.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.