LinuxおよびUnixのlost + foundフォルダーの目的は何ですか？

644

LinuxおよびUnixオペレーティングシステムのルートにあるフォルダーがあります。 /lost+found/

それはなんのためですか？どのような状況でそれとやり取りしますか？どのようにやり取りしますか？

filesystems directory-structure lost-found

— ウェズリー
ソース

ext2（およびext3およびext4）のみがを使用することに注意してくださいlost+found。非表示にする場合は、別のファイルシステムを使用するか、別の場所にマウントし、サブディレクトリにすべてを保持し、データを使用する「実際の」場所にサブディレクトリをシンボリックリンクします。

— アダムカッツ

誰かが親切にそれを追加することでした@Gilles：en.wikipedia.org/wiki/Fsck#Use

— デヴィッド・ケネディ

これlost+foundは、Linux拡張ファイルシステム（ext2–4）に固有のものであることに注意してください。ユニックス、たとえばFreeBSDは通常、ファイルシステム（UFS、ZFS）にこのディレクトリを持ちません。

— FUZxxl

申し訳ありませんが、lost+foundBSDシステムではほぼ永久に使用されています。実際、私はチェックしたところ、4.3BSDには間違いなく存在していましたが、かなり早く思い出すようです。そして、今日のFreeBSDには確かにあります。

— ボブ・イーガー

@BobEager確認いただきありがとうございます。私もそれを考えましたが、多分私は間違って覚えていたことを受け入れるつもり

— でした...-Pryftan

回答:

577

fsckファイルシステムのチェックと修復コマンドを実行すると、ファイルシステム内のどこでも参照されていないデータフラグメントが見つかる場合があります。特に、fsck完全なファイルのように見えるがシステム上に名前がないデータ、つまり対応するファイル名のないiノードを見つける可能性があります。このデータはまだスペースを消費していますが、通常の方法ではアクセスできません。

fsckファイルシステムの修復を指示すると、これらのほとんど削除されたファイルがファイルに戻ります。実は、ファイルには名前と場所が一度しかありませんでしたが、その情報はもう利用できません。したがってfsck、ファイルを特定のディレクトリに保存します。これは、プロパティの紛失と発見lost+found後です。

に表示さlost+foundれるファイルは、通常、既にリンク解除されている（つまり、名前が消去されている）が、システムが突然停止した（カーネルパニックまたは電源障害）ときに何らかのプロセスによって開かれた（したがって、データはまだ消去されなかった）ファイルです。それがすべてである場合、これらのファイルはいずれにせよ削除する予定であるので、それらを気にする必要はありません。

lost+foundソフトウェアまたはハードウェアのバグによりファイルシステムが一貫性のない状態にあったため、ファイルが表示されることもあります。その場合は、失われたがシステムの修復がなんとか回復したファイルを見つける方法です。ファイルには有用なデータが含まれている場合と含まれていない場合があり、たとえ含まれていても不完全であるか古い場合があります。それはすべて、ファイルシステムの損傷がどれほどひどかったかにかかっています。

多くのファイルシステムでは、lost+foundディレクトリはファイルを置くためのスペースを事前に割り当てるため、少し特別fsckです。（スペースは、ファイルデータのためではないfsck場所に残し、それはディレクトリエントリのためだfsck補うために持っている。）誤って削除した場合lost+found、再作成していないことでmkdir、使用mklost+found可能な場合。

— ジル
ソース

また、誤ってfsckを削除すると、次にファイルシステムがクリーンになったときに再作成される可能性があります（おそらく次のブートになります）。

— デロバート

このフォルダは、時々チェックしてクリーニングする必要があるものですか？

— TheLQ

@TheLQあなたのファイルシステムが大規模な破損に苦しんでいる場合にのみfsck必要であり、ファイルを見つけてそれらをリンクすることに言及しましたlost+found。さまざまなファイルシステムを使用して20年で、これを一度しか見ませんでした。そして、それはジャーナリングが標準になる前でした。

— アレクシオス

私は（私はext4のにNTFSから切り替えると、それは登場）あなたのHDDをフォーマットした場合、それはまた、表示されたと思う

— PUK

@puk lost+foundディレクトリは、システムのインストールの一部として実行されるかどうかに関係なく、ext4ファイルシステムを作成するたびに（他の多くのファイルシステムと同様に）作成されます。「HDDをフォーマットする」というのはその一例です。何fsck行うことは、おそらくそこにあるファイルを追加することです。

— ジル

lost+foundディレクトリは、（実測+失われていない）によって使用される構築物であるfsckファイルシステム（ないハードウェアデバイスに、しかしFSに）に損傷がある場合。通常、ディレクトリの破損により失われるファイルは、そのファイルシステムのlost+foundディレクトリ内でiノード番号によってリンクされます。これらの一部は、ディレクトリやファイルの紛失、さらにはデバイスの紛失の可能性があります。各ファイルシステムには独自のlost+foundディレクトリが必要ですが、ファイルシステムが1つしかないシステムを見ている場合があります。一般に、ディレクトリが空であることを期待する必要があります。ただし、破損がある場合は、多くの条件でファイルをfsckここに配置した後に復元できることに感謝してください。

— アルセゲ
ソース

ただし、有効な点：これらのCANはとにかく迷惑になります。たとえば、管理者以外のユーザーのアカウントからfind1つまたは複数のext[2|3|4]パーティションで操作を行おうとすると、これらの完全に不要な「許可が拒否されました」エラーが常に発生します。確かに、この種のエラーを回避する方法はありますが、標準でfind . -name '*whatever*'はうまくいかないため、少し厄介です。

— 構文エラー

@syntaxerror：findの煩わしさについてあなたが言ったことを聞いてうれしいです： `./lost+found '：許可が拒否されました。それはあまりにも随時バグ私を...

— ヨハン・E

@syntaxerrorこの質問にたどり着いた理由は、まさに検索操作を行っていて、findがPermission denied警告を生成し続けていたからです。この質問の答えを考えるlost+foundと、それがファイルシステムの一部であることがわかっているので、生成された警告を安全に無視できます（ただし、警告が生成されないことを望みます）。

— トレバーボイドスミス

@JohanEあなたは私に言っている。しかし、私がコメントを投稿した実際の理由は、この回答が私たちに「感謝する」ことを提案しようとしていたためlost+foundです。これは途方もなく数回のために、（私は広範なにやにや笑いとここに座って）本当であるにはあまりにも陽気な感じた私たちは、むしろキャストすることができるだろうとき、それらと競合することはできませんそれに感謝している「仰せられましたの！」この厄介なlo + foのことを綴ります。

— 構文エラー

「Linux Filesystem Hierarchy」のセクション/ lost + foundから：

FSSTNDの概要で説明したように、Linuxは常に適切なシャットダウンを行う必要があります。システムがクラッシュしたり、停電によってマシンがダウンする場合があります。どちらの方法でも、次回の起動時に、fsckを使用した長いファイルシステムチェックが行われます。Fsckはシステムを通過し、見つかった破損ファイルを回復しようとします。この回復操作の結果は、このディレクトリに配置されます。復元されたファイルは完全ではないか、あまり意味がありませんが、価値のあるものが復元される可能性は常にあります。各パーティションには、独自のlost + foundディレクトリがあります。そこにファイルが見つかったら、元の場所に戻してみてください。「ファイル」への壊れたシンボリックリンクのようなものを見つけた場合、対応するRPMからファイルを再インストールする必要があります。ファイルシステムがひどく破損し、ファイルが認識できないほど破損したためです。以下は、/ lost + foundディレクトリの例です。ご覧のとおり、ここに含まれるファイルの大部分は実際のソケットにあります。他のファイルの残りの部分に関しては、それらは破損したシステムファイルと個人ファイルであることがわかりました。これらのファイルは回復できませんでした。

— ブーパル
ソース