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 fsck deposits 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.
Last time I had to do that - many years ago - you had to guess based on file content. I doubt there is a better way today.
The 'file' program can help here since it will give you an idea of the type of data, so you can use this to view the files appropriately for a start.
Best Answer
In case the
lost+founddirectory doesn't exist. Since it's just an ordinary directory, therootuser can remove it usingrm -r. Some versions offsck, when they need to make use of alost+founddirectory, will create it if it doesn't exist, and some versions won't. If there's nolost+founddirectory,fsckcan't recover orphaned files, that is, files that do not have any directory entries that refer to them.The Linux version of
mklost+foundhas the following feature (from the mklost+found man page):This means that, if you have to recover files from a damaged filesystem using
fsck, fewer files will be lost as part of the recovery process becausefsckwon't need to allocate blocks from the filesystem; such blocks which may contain valid file data.For a given filesystem,
fsckwill only use onelost+founddirectory: the one that is at the filesystem's root directory. Any otherlost+founddirectory will not be treated specially.