How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I had a lost+found folder in all Unix file systems I used since the 80s. It's where fsck places files that it found during a scan and can't figure out to which directory they belong. Sometimes I found stuff in there.
From what I googled XFS, Btrfs and ZFS don't use lost+found. It's a thing of the old not journaled filesystems and of the ext family.
I have a book on my bookshelf, Eric Foxley's Unix for Super-Users. It was published in 1985, and it answers this question on page 52, the first page listed for the entry 'lost+found' in its index.
This is surely not the earliest book mention, is it? (It'll be in earlier man pages, of course.) Google Books does not give me an earlier one, although it does yield another 1985 book.
Fun fact: Foxley cautioned that lost+found must be pre-sized ahead of time, because the fsck of the time did not grow the directory to fit found files.
That's what the answers are missing, of course. In some filesystem formats, it's possible either to recover completely from a journal/intent log, or at least to recover everything to the point that recovered files can be placed into the correct directory.
Yeah, exactly. We ran into this on ext3 years ago — journal replay put everything back clean, nothing in lost+found. Saw it fill up once on an older ext2 volume with no journal. Night and day difference.
Same here. And I had some pretty f**ed up file systems.
At one point, I had one where the directory structure was completely broken and had circles in it (broken SSD). To be fair, in that particular case, I did not look for lost+found and just wrote a tool to extract the data manually that I was looking for.
But does fsck actually populate lost+found when the directory structure itself is circular? I'd guess it only handles simpler cases -- inodes with no parent. Your case sounds like it would've stumped fsck entirely anyway.
SD cards writing to lost+found means fsck ran and found orphaned inodes. That filesystem is already dying. Stop trusting it with anything you care about.
The lost+found folder saved our backs once way back when. We had a 1TB NAS running Linux, an enormous amount of storage back then. It was shut down unexpectedly and disorderly and ran a multi hour fsck upon reboot. The volume must have had a shot root inode, as after the machine booted and mounted the volume it was empty. All directories were luckily under lost+found with all their contents.
We once deleted the lost+found folder on an old Unix system* by accident. Things went very badly the next time the system rebooted, fsck did not handle it at all well.
As the submission explains, the lost+found folder has pre-allocated space for the directory entries. From the mklost+found man page [0]:
mklost+found pre-allocates disk blocks to the lost+found directory
so that when e2fsck(8) is being run to recover a file system, it
does not need to allocate blocks in the file system to store a
large number of unlinked files. This ensures that e2fsck will not
have to allocate data blocks in the file system during recovery.
Pre-allocating space without making the directory visible would require more arcane file system magic.
Back in the day I accidentally deleted all my stuff because I had it all in a special dir of this user in suse Linux. When I deleted the user, yast deleted everything.
Fortunately I was using ReiserFS at the time and something about its murderous tree data structure made it trivial to undelete.
Reiser_fsck found ALL my stuff, mostly with full dir tree structure in tact and put it all in lost+found
they offer private instances to school too, where moderation is left to school policy, and mine seems to be good enough to use whenever i have frontend questions (i'm 10 year into my career and still use my juniors to answer my frontend questions, i think i won't ever change)
lost+found is still used on OpenBSD, seems it is created when needed. Only /home has that directory on my system. IIRC, it was created when a kernel panic happened a few releases ago. Plus some files were placed in it when fsck executed on /home
Same, it's only in /home on my system also. Also /home is pretty much the only directory where I see fsck needing to do a lot of recovery after a power failure. Makes sense I guess, because that's where processes such as web browsers are likely to have lots of files open in RW mode.
Not really, as it's only once per file system mount, whereas those Windows and MacOS files are sprinkled in most directories with images and almost every non-network drive directory respectively.
Actually, lost+found isn't really hidden like those files — it's a normal visible directory. The comparison's more about "weird system cruft you never touch." Fair analogy in that narrower sense, I guess.
How do questions like this make it to the top? It is an obvious thing if you search for it or ask AI, but people seem to just ignore those in favor of generating new human responses.
Thing is, any time I try to replicate something like that, I basically get a flippant response saying to go look elsewhere.
The pre-allocation aspect is underappreciated -- ext2/ext3 reserves inodes in lost+found at mkfs time precisely because inode table expansion during fsck isn't possible. As far as I know, this distinguishes it from a simple staging directory.
From what I googled XFS, Btrfs and ZFS don't use lost+found. It's a thing of the old not journaled filesystems and of the ext family.