If you run fsck, the filesystem
check and repair command, it might find data fragments that are not referenced
anywhere in the filesystem. In particular, fsck might
find data that looks like a complete file but doesn‘t have a name on the system
— an inode with no
corresponding file name. This data is still using up space, but it isn‘t
accessible by any normal means.
If you tell fsck to repair the filesystem, it will
turn these almost-deleted files back into files. The thing is, the file had a
name and location once, but that information is no longer available.
So fsckdeposits the file in a specific directory,
called lost+found (after lost
and found property).
Files that appear in lost+found are typically files
that were already unlinked (i.e. their name had been erased) but still opened by
some process (so the data wasn‘t erased yet) when the system halted suddenly
(kernel panic or power failure). If that‘s all that happened, these files were
slated for deletion anyway, you don‘t need to care about them.
Files can also appear in lost+found because the
filesystem was in an inconsistent state due to a software or hardware bug. If
that‘s the case, it‘s a way for you to find files that were lost but that the
system repair managed to salvage. The files may or may not contain useful data,
and even if they do they may be incomplete or out of date; it all depends how
bad the filesystem damage was.
On many filesystems, the lost+found directory is a bit
special because it preallocates a bit of space
for fsck to deposit files there. (The space isn‘t for the
file data, which fsck leaves in place; it‘s for the
directory entries which fsck has to make up.) If you
accidentally delete lost+found, don‘t re-create it
with mkdir, use mklost+found if
available.