Why can't a filesystem create the lost+found folder only when it needs to store files in it?
That would be a much cleaner approach, imho.
Added benefit is that you'd immediately see it if something is wrong with a disk.
That would be a much cleaner approach, imho.
Added benefit is that you'd immediately see it if something is wrong with a disk.
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.
[0] https://man7.org/linux/man-pages/man8/mklost+found.8.html
If those filesystem engineers had a manager that said: make this nice for the user, then it would have been done.
But these developers had no managers and were OK eating their own unpalatable dogfood.
Also remember that these systems would have all been multi-user time-sharing systems, not desktop computers.
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.