Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The system in my laptop is Windows Vista. I am not able to delete the found.002 folder. What is it and how can I delete it?

I have tried del found.002. But it didn't work at all.

enter image description here

EDIT: Thanks to the answer, I've been able to remove the folder found.002 and found.003. But I'm not able do so for found.004. The character in the second figure means "Access denied" in English.

enter image description here

share|improve this question
up vote 2 down vote accepted

You can delete the folders via Explorer, or from the command line as: rd /s /q found.002 or whatever else the folder is.

Keep in mind that the rd /s /q will fully delete the directory without confirmation, so ensure you want to delete this directory before running it.

share|improve this answer
Thanks for your answer. I've succeeded in removing the folder found.002 and found.003. But when I tried found.004, it is showed that access denied. – Jack Jan 10 '12 at 10:46
@Jack: Open an elevated Command Prompt ("Run as Administrator" in the English version), then try again. If it still does not work, use take ownership using takeown /f found.004, then rd should start working. – grawity Jan 10 '12 at 12:34
@grawity: Still not work. I've edited the question accordingly. – Jack Jan 10 '12 at 13:12
@Jack: Oh, perhaps takeown /f /r found.004 will help. I forgot to add /r for "recursive" mode. – grawity Jan 10 '12 at 13:54
As @grawity you should try taking ownership first, reset the ACL & then try deleting – Sathya Jan 10 '12 at 14:12


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 FILEnnnn.CHK and DIRnnnn.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 lost+found.

This 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 chkdsk, format, sys, and recover anyway.

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 FILEnnnn.CHK and DIRnnnn.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 found.nnn directories:

  • 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 FILEnnnn.CHK and DIRnnnn.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 FILEnnnn.CHK and DIRnnnn.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 DIRnnnn.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: EAnnnn.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 (EA DATA. 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 EAnnnn.CHK file or simply marked as free space.

share|improve this answer
The OP's asking for information on how to remove it - have you misunderstood the question? – Sathya Jan 10 '12 at 13:52
No, but you definitely have. Read carefully. The questioner not only asked "What is it?" as well, but asked that first. The above answers both that and how to delete it, albeit the latter differently to "just use the rd command". But that's because it gives the information as to why arbitrary users cannot delete the directory and why that is by design, and indeed why one might want to look in the directory first. Remember our mandate to give people explanations, not just raw recipes for robots. – JdeBP Jan 10 '12 at 15:02
that I seem to have. Thanks. – Sathya Jan 10 '12 at 15:25
What decides whether extended attributes are recovered or discarded? – Daniel Beck Jan 13 '12 at 8:49
On OS/2 it is the user answering yes or no to the question in the SYS1315 message that CHKDSK prompts xem with. ☺ – JdeBP Jan 19 '12 at 21:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.