In the days of MS-DOS and PC-DOS, the
chkdsk utility, when it recovered lost files (i.e. files that still had space allocated for them in the FAT but that weren't listed in any directory), it would create directory entries for them in the root directory, named
.CHK . At the time, the
fsck program on Unices was, in contrast, placing such orphaned files that it found in a sub-directory of the root named
chkdsk strategy was a poor one for several reasons, not the least of which is that on FAT12 and FAT16 volumes the root directory has a fixed size, and isn't variable-length like other directories. If there were too many lost files,
chkdsk would end up filling the root directory. So come the time that IBM and Microsoft brought out HPFS, which was in OS/2 version 1.2, a change was made, since providing HPFS support required a wholesale revamp of tools like
The OS/2 version of
chkdsk thus was implemented to do what
fsck did. It created subdirectories in the root directory, and placed the new directory entries for recovered files there. It didn't use a fixed subdirectory name, as
fsck did, though. Instead it tried to create a
found.nnn directory, where nnn started at
000 and was incremented until it didn't clash with any existing subdirectory. In that directory would be all of the
.CHK files. It is still possible to fill the root directory (on FAT12 and FAT16 anyway — HPFS doesn't have fixed-size root directories), just that it requires the pathological scenario of someone who corrupts the filesystem a lot and never pulls recovered files and directories out of the recovery directory.
fsck uses a fixed single subdirectory because many Unix filesystem formats have fixed-size inode tables. In contrast, HPFS and NTFS don't have fixed size tables for holding f-nodes and MFT entries, and FAT doesn't even have such things in the first place. When one has a fixed-size table, one can potentially hit the situation where there are no free i-nodes available to use as a new recovery subdirectory but one has orphaned i-nodes to recover.
fsck avoids this deadlock by requiring, for proper operation, that the system administrator have created
lost+found ahead of time, and only ever using that same directory every time. Of course, it will create
lost+found if it doesn't exist, but that opens the door for the aforementioned deadlock to occur.)
A lot of "DOS commands explained" WWW sites won't tell you this about
chkdsk, even though it has worked this way on the operating system that you and most people now have for two decades. They'll instead still tell you how the old MS-DOS
chkdsk worked. OS/2 version 1.2 came out in 1989. Windows NT, whose first version was in 1993, inherited several things from OS/2 1.x, including this behaviour of
chkdsk. In the meantime, the DOS and DOS+Windows world carried merrily on for the next decade, without noticing — or ever incorporating — these
chkdsk improvements from the late 1980s. The DOS and DOS+Windows world, and all of the books and WWW sites that sprang up to tell one how they worked, remained stuck in 1985, effectively. However, the DOS and DOS+Windows world has finally died its long-deserved death, Windows NT isn't DOS, and never has been, and the
chkdsk command in Windows NT stopped being the same as the DOS
chkdsk command in the late 1980s. The behaviour of the command is not the behaviour that those people who erroneously think that it is a "DOS command" will tell you.
Rationale and operation
One of the reasons that
fsck operates as it does is that it was designed for an operating system that was already multi-user in the 1980s. On a secure multi-user operating system, it is a security problem if recovering files after a disc crash means that everyone can access them where they couldn't before. You'll find that the standard permissions for
lost+found on any Unix or Linux system are thus 0700 (
rwx------) with owner
root. Only the superuser can access the contents of the directory. So if the file wasn't in a group-accessible/world-accessible directory before, it doesn't suddenly become accessible to people as a result of recovering from filesystem corruption.
chkdsk on Windows NT faces the same issues, which is why you'll find that
found.nnn directories are only accessible by an administrator on NTFS volumes. (On FAT volumes, there are no filesystem ACLs, so it's not possible to secure things this way. However, the files in their original locations weren't secured either; so this is not introducing a security hole.) This is also why you'll find that the directory underlying the Recycle Bin on NTFS volumes is structured as it is. Deleting files doesn't make them suddenly accessible to other people who would have had no access to them in their original directories.
When it comes to names in the top-level
- By their very natures, recovered orphaned files and directories don't have names on FAT volumes. The names would have been in directory entries pointing to the files, but the files/directories didn't have directory entries pointing to them. This is why the
.CHK names are used. Names have to be invented for the files and directories.
- On HPFS volumes, it's possible to recover the name of an orphaned file, since it is stored in the f-node as well as in the directory entry pointing to the f-node. But you'll still find
.CHK names being used.
- On NTFS volumes, one generally doesn't see orphaned files recovered this way at all, since the MFT entry contains the file/directory names and the MFT entry numbers of the originally containing directories. So recovery of lost files and directories on NTFS can actually place them back in the directories that they were lost from, and usually (but not always) doesn't even need a
found.nnn directory at all. (It does if no originally containing directory can be recovered to place the file into, of course.) This is why one rarely sees
found.nnn directories on NTFS volumes, as compared to FAT volumes.
Of course, the names of the files and directories within a recovered directory will be retained, since they weren't lost in the first place. They were, rather, directory entries within a directory that itself was lost. So everything below a
.CHK directory at the top level will have its original name.
On HPFS volumes, a lost file/directory is an (allocated) f-node that doesn't have a directory entry pointing to it. On NTFS volumes a lost file/directory is an (allocated) MFT entry that doesn't have a directory entry pointing to it. In both cases, the entire space allocated to the file/directory is recorded in the f-node/MFT entry, and any conflicts with the volume allocation bitmap are resolved in favour of allocating the space to the f-node/MFT entry. On FAT, things are different. There are no f-nodes, i-nodes, or MFT entries. The only way to find lost files/directories is to look in the FAT for chains of clusters that have no directory entries pointing to them, and the FAT is the allocation map as well. Thus it's not possible to detect the difference between a truly lost file/directory and a file/directory fragment that simply wasn't marked as free in the volume allocation map. So oftentimes on FAT one finds that recovered files or directories are partial files or directories. (This is not to say that it's impossible to get partial files/directories on HPFS and NTFS. It's just that the necessary circumstances for that are a lot rarer, and on NTFS largely avoided completely by dint of metadata journalling.)
Again, on HPFS and NTFS it's possible to determine from the f-node/MFT entry whether a recovered node/entry is a file or directory. There's a flag in the f-node/MFT entry saying what it is. This is not the case with FAT. At best one can apply heuristics to look at the contents of the clusters and guess what the thing originally was. So sometimes, if the contents happen to look right, a lost directory can be recovered as a file, and vice versa.
One final note: There is a third type of recovered file on FAT volumes:
.CHK. This is another OS/2 1.x innovation that lasted into Windows NT. These files contain lost extended attributes. Sets of extended attributes are held within a special container file (
SF) on FAT volumes. If no directory entry points to a particular set of extended attributes, that set of EAs is considered lost, and either recovered as an
.CHK file or simply marked as free space.