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.
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.
Chicken and egg problem.
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.
As the submission explains, the lost+found folder has pre-allocated space for the directory entries. From the mklost+found man page [0]:
Pre-allocating space without making the directory visible would require more arcane file system magic.[0] https://man7.org/linux/man-pages/man8/mklost+found.8.html
> Preallocating space without making the directory visible would require more arcane file system magic.
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.
You greatly overestimate the capabilities of computers of the era that this originated in. Major limitations of disk space, speed and addressability combined with limited CPU power and RAM mean that your hypothetical, “it could have been done” would require a significant investment in development and runtime resources all to avoid having a directory in root that would be empty until after a post-crash recovery.
Also remember that these systems would have all been multi-user time-sharing systems, not desktop computers.
Sorry, but I just don't believe all this. We're talking about hiding a folder. Of course the developers could do that.
well sure, they could have named it .lost+found instead of lost+found, but you’re overestimating the value of hiding it.
It's at the root level, no user came near that back then so it was kinda hidden.
Because you need to pre-allocate space and indies for it in case things go wrong and the disk is almost full