Timeline for What is the purpose of the lost+found folder in Linux and Unix?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 12 at 19:20 | comment | added | SamB | @Ruslan even empty files have inodes | |
| Dec 22, 2024 at 19:15 | comment | added | Daniel | I $ sudo rmdir lost+found in a few places and recreated it with $ mklost+found (without using sudo) and now I no longer have permission denied errors when using find which ends up being a unexpected benefit. | |
| Sep 16, 2022 at 15:36 | comment | added | Gilles 'SO- stop being evil' | @DanielGriscom At least in the case of ext2/ext3/ext4, lost+found has to be called by that name and to be at the root of the filesystem. I don't know if that's the case for all filesystems. | |
| Sep 16, 2022 at 15:03 | comment | added | Daniel Griscom | Great answer, but related question: is lost+found always created at the root of a file system? | |
| Jan 26, 2020 at 8:31 | comment | added | Ruslan | I've now come across several empty files in this directory. How could they be gathered by fsck? There should have been any unreferenced occupied blocks if the restored files are empty. | |
| Jan 27, 2017 at 9:34 | comment | added | Gilles 'SO- stop being evil' | @BalmanRawat fsck does not go through the filesystem driver at all. It accesses the disk directly. The filesystem does not need to be mounted. If it's mounted, it's mounted read-only with most filesystem types because it would be very hard to make fsck work if the filesystem got modified by the driver at the same time. In fact, it would be easier to make a filesystem driver that doesn't work at the same time as fsck, but many filesystem tools support read-only mounting so that fsck can act on the partition where the fsck binary itself is located | |
| Jan 27, 2017 at 2:48 | comment | added | Balman Rawat | I am wondering how does fsck writes in lost+found directory since fsck is ran when the filesystem is on Read Only Mode. | |
| Aug 28, 2015 at 15:04 | comment | added | budhajeewa | If you run fsck when there is no lost+found directory, it'll ask your permission to create it. | |
| Nov 18, 2014 at 19:10 | comment | added | Luis Antolín Cano | At RHEL 6.4 nor fsck neither e2fsck where re-creating this for me, no matter if the directory was mounted or not. cd <root-dir-of-the-mount> && mklost+found did it. | |
| S Jun 21, 2014 at 19:51 | history | suggested | Cristian Ciupitu | CC BY-SA 3.0 | added link to man page |
| Jun 21, 2014 at 19:49 | review | Suggested edits | |||
| S Jun 21, 2014 at 19:51 | |||||
| Feb 5, 2014 at 20:56 | comment | added | erch | fdisk (util-linux 2.20.1) does this when creating an ext2 system too | |
| Nov 20, 2013 at 10:17 | comment | added | Gilles 'SO- stop being evil' | @puk The lost+found directory is created whenever you create an ext4 filesystem (as with many other filesystems), whether it's done as part of the system installation or not. “Format your HDD” is just one case of that. What fsck does is to possibly add files there. | |
| Nov 20, 2013 at 8:43 | comment | added | puk | I think it also appears if you format your HDD (I switched from NTFS to ext4 and it appeared) | |
| Jan 12, 2012 at 8:06 | comment | added | Alexios | @TheLQ Only if your filesystem has suffered extensive corruption, fsck was required, and it mentioned finding files and linking them in lost+found. In 20 years with various filesystems, I've only seen this once. And that was before journalling was the norm. | |
| Aug 9, 2011 at 3:20 | vote | accept | Wesley | ||
| Aug 7, 2011 at 8:24 | comment | added | TheLQ | Is this folder something that should be checked and cleaned from time to time? | |
| Aug 6, 2011 at 5:05 | comment | added | derobert | Also, if accidentally deleted fsck may re-create it the next time it finds the filesystem clean (which will probably be the next boot). | |
| Aug 5, 2011 at 21:23 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 3.0 |