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.
Foxleys book does not actually claim reason why it need to be preallocated. I've got the book also. Index mentions fsck only page 52, where it reads:
"52 UNIX FOR SUPER-USERS
...
The filestore consistency check is performed by the command fsck (usu-
ally stored as /etc/fsck, but sometimes in /bin), which should be used to check
all discs used as file-systems. It defaults to the list of filestore devices given
in the file /etc/checklist. At this stage, most of the file-systems will not be
mounted, so will be inactive; only the root file-system will be active. The
fsck command goes through each one in turn, reports any inconsistencies in
them, and offers to correct them. The reply to each query is either 'y' for yes
(correct the inconsistency), or 'n' for no (leave the file-system inconsistent).
A parameter '-y' to the command assumes 'yes' replies to all questions, so
that no further interaction is necessary; a parameter '-n' similarly assumes
all 'no' answers, and therefore needs no write permission to the device. Any
'yes' reply may involve the loss of information, such as the complete removal
of a suspect file. Suspect files on the file-system being checked are written to
a directory lost + found on the device if such a directory exists; this directory
must have been created, and be sufficiently large already to hold the names
of all the files involved. This can be ensured by first creating the directory,
then creating a number of files in the directory, and then removing them.
The corrected systems will be consistent, and can later be mounted as and
when required. It may be possible to recover information from deleted files
by looking at the lost + found directory. There should be a lost + found direc-
tory at the head of each mountable file-system.
When checking the root file-system, there are complications, in that it
will be active (even though, because it is root, it will not be formally mounted
as such, but is implicitly mounted as root during the booting process). If
modifications are necessary, they should be completed, and the machine
rebooted without first performing a sync (see section 4.5 below for the nor-
mal procedure for taking a system down). This is to ensure that the disc as
modified by fsck is not overwritten by any in-core information, which may
have been generated from information read from the original corrupt (incon-
sistent) version.
...
"
But I've also read more detailed explanation that recollect is that unless blocks were preallocated, there was a possibility that lost+found need first allocate more blocks directory it already had, it would possibly led to losing some data that would otherwise been able to recover once fsck had advanced further from that point.
Old time UNIX systems directories were just another structured file, which a 'd' bit (like others you changed with chmod) on them, where each record was 16 bytes, which 2 first were the inode number followed by 14 bytes reserved for filename. IIRC linux also had first same limit first filesystems. You could read directory with any program, common feat was to check any odd stuff that "ls" would not show with could hexdump or "od" with some flags and print 16 bytes lines per row. That way you also could see any deleted or moved files from that directory, because directory entry was not quite long otherwise cleared but just clearing that inode reference two bytes.
A Quick look from other books that I have close me now Maurice J. Bach, The Design of Operating UNIX System (-86) contains much more about fsck and filesystem fixing issues scattered few pages in the book and what methods were used to mitigate loss of data. S.R Bourne The Unix System, no mention of fsck at all, at least by looking book automatically generated index.
It could have been some other quite old book I did read, but did not...
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
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.
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
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.
On the UFS and suchlike filesystems, at the point that fsck is rescuing orphaned i-nodes, it still has not fully gone through the process of checking and correcting free list information, or indeed fully eliminating errors from the i-node table. Creating a directory involves allocating a new i-node from an unused slot, and free blocks off the free block list.
Ironically, because they are slightly or grossly different to Unix filesystem formats, on HPFS and FAT this is less of an issue. (FAT usually has unused slots in the root directory that it is sane to use at that point, for example.) CHKDSK on OS/2 did create its \FOUND.nnn files on the fly.
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.
rmdir /lost+found is always my first step after creating and mounting a new file system. Reserving a user-visible directory just so that a 0.00001% chance recovery is slightly easier just doesn't make any sense.
20 comments
[ 3.0 ms ] story [ 38.2 ms ] threadFrom 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 saw it often. Running fsck on a crashed/failed partition usually does put some files in there. Maybe I kept using old hardware too long...
In reallife I would rename this to "trash".
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.
Old time UNIX systems directories were just another structured file, which a 'd' bit (like others you changed with chmod) on them, where each record was 16 bytes, which 2 first were the inode number followed by 14 bytes reserved for filename. IIRC linux also had first same limit first filesystems. You could read directory with any program, common feat was to check any odd stuff that "ls" would not show with could hexdump or "od" with some flags and print 16 bytes lines per row. That way you also could see any deleted or moved files from that directory, because directory entry was not quite long otherwise cleared but just clearing that inode reference two bytes.
A Quick look from other books that I have close me now Maurice J. Bach, The Design of Operating UNIX System (-86) contains much more about fsck and filesystem fixing issues scattered few pages in the book and what methods were used to mitigate loss of data. S.R Bourne The Unix System, no mention of fsck at all, at least by looking book automatically generated index.
It could have been some other quite old book I did read, but did not...
Thing is, any time I try to replicate something like that, I basically get a flippant response saying to go look elsewhere.
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
* Probably DEC Ultrix 2.2, a BSD 4.2 derivative.
That would be a much cleaner approach, imho.
Added benefit is that you'd immediately see it if something is wrong with a disk.
On the UFS and suchlike filesystems, at the point that fsck is rescuing orphaned i-nodes, it still has not fully gone through the process of checking and correcting free list information, or indeed fully eliminating errors from the i-node table. Creating a directory involves allocating a new i-node from an unused slot, and free blocks off the free block list.
Ironically, because they are slightly or grossly different to Unix filesystem formats, on HPFS and FAT this is less of an issue. (FAT usually has unused slots in the root directory that it is sane to use at that point, for example.) CHKDSK on OS/2 did create its \FOUND.nnn files on the fly.