Quando você cria alguns sistemas de arquivos Linux como o ext3, um diretório 'lost + found' é criado. De acordo com esses arquivos serão colocados lá se os arquivos forem danificados por algum tipo de pane no sistema .
O que acontece se esse diretório for removido e o sistema falhar. Se a pasta for removida, posso apenas criar um novo diretório com mkdir lost + found ou existem atributos que só podem ser definidos quando o sistema de arquivos está sendo criado.
fsck irá recriar o diretório lost + found se estiver faltando.
Na inicialização, a maioria das distribuições executa o fsck se o sistema de arquivos for detectado como não sendo desmontado corretamente. Como o fsck cria o diretório lost + found se ele estiver faltando, ele irá criá-lo e colocar qualquer coisa que encontrar nesse diretório.
Se você não puder ou não quiser executar fsck , poderá recriar os diretórios lost+found com mklost+found :
mklost+found pre-allocates disk blocks to the lost+found directory so that when e2fsck(8) is being run to recover a filesystem, it does not need to allocate blocks in the filesystem to store a large number of unlinked files. This ensures that e2fsck will not have to allocate data blocks in the filesystem during recovery.
Um diretório preexistente perdido + encontrado com um tamanho grande o suficiente para conter um grande número de arquivos desvinculados coloca menos peso no e2fsck para criar o diretório e expandi-lo para o tamanho apropriado.
Ele ainda tentará fazer isso, mas em face de um sistema de arquivos corrompido, pode ser mais arriscado.
Fsck's muito antigos para outros sistemas de arquivos em outras plataformas não foram capazes de criar / lost + found, nem foram capazes de desenvolvê-lo. Esta é a história da lógica de / lost + found. Mas a lógica atual é simplesmente tornar o trabalho do e2fsck mais fácil.
Se você não tiver lost+found , e2fsck (não inspecionei o código em outras fsck implementações) oferecerá para criá-lo para você. Mas você também pode recriá-lo se quiser; não há nada particularmente especial sobre esse diretório (pelo menos não de inspecionar o código).
O e2fsck recriará o lost + found e também destruirá qualquer arquivo que possa estar no caminho com o mesmo nome para garantir que ele possa ser criado como um diretório.
Note que muitos sistemas de arquivos Unix antigos exigiam que o lost + found fosse anexado ao inode número 2 especificamente, daí a necessidade de recriar o sistema de arquivos na maioria dos casos se o diretório fosse perdido. O e2fsck simplesmente faz uma busca por qualquer inode livre, aparentemente não precisando especificamente do inode 2, o que torna a recuperação muito mais simples do que nos velhos tempos.
Você pode criar esse diretório usando apenas mkdir. Deve ser propriedade da raiz, com um grupo de raiz ou roda. Fora isso, não há nada de especial nisso. No caso de uma falha de energia ou desligamento incorreto quando o sistema for inicializado, ele deve iniciar automaticamente o fsck. O fsck passará pelo sistema e tentará recuperar qualquer arquivo corrompido que encontrar. Todos os arquivos que forem encontrados e potencialmente corrompidos serão movidos para lá.
O outro caso para arquivos a serem movidos para lá é se o fsck encontrar um arquivo cujo inode pai está faltando. Este é geralmente o caso se um bloco for corrompido no disco no local específico onde o inode de uma pasta está sendo armazenado. Ele irá reatribuir seu inode pai para ser a pasta perdida + encontrada.
Edit: Não tenho certeza se o último caso irá recriar o diretório. Eu deixaria sozinho para estar no lado seguro. Não consigo pensar em nenhum motivo para excluí-lo. Nada de ruim vai acontecer sem isso.
Além disso, no Debian 6 e no Ubuntu 12 LTS, o pacote cron enviou /etc/cron.daily/standard , que percebe a falta de diretórios lost+found em sistemas de arquivos locais e envia lembretes diários sobre ele via e-mail, recomendando o uso de mklost+found .
No entanto, isso foi removido no momento do Debian 7 e do Ubuntu 14 LTS, respectivamente, porque se tornou obsoleto.