This article was previously published under Q169404
A directory in which files are repeatedly created and deleted eventuallybecomes corrupt. Subsequent attempts to access files in the directory or tocreate or delete files in the directory yield pop-up window indicating thatthe directory is corrupt and instructing the user to run CHKDSK.
When CHKDSK is run, it generates output like the following (although thespecific file record segments affected will vary):
Deleting corrupt attribute record (16, "") from file record segment 286. Deleting corrupt attribute record (32, "") from file record segment 286. Deleting corrupt attribute record (48, "") from file record segment 286. Deleting corrupt attribute record (80, "") from file record segment 286. Deleting corrupt attribute record (144, $I30) from file record segment 286. Deleting corrupt file record segment 286. Deleting orphan file record segment 8628. Deleting index entry DirectoryName in index $I30 of file 244. CHKDSK is recovering lost files.
Multiple attributes associated with a given file have the same attributeinstance tag value. This is only likely to happen in directories where manyfiles are repeatedly added and deleted in an "unbalanced" way.
To resolve this problem, you can do one of the following:
Run CHKDSK /f. By running CHKDSK /f, all files contained in a directory that is corrupted in this way should be recovered. CHKDSK is also capable of detecting when instance counts are exceptionally large and will proactively renumber attribute instance values. Specifically, if an attribute instance tag is larger than 0xF000, CHKDSK will send the following message (file number will vary):
Adjusting instance tags to prevent rollover on file 252.
Thus, by periodically running read-only CHKDSK, it is possible to detect problem directories before they become corrupt. If the above message is encountered while running CHKDSK in read-only mode, you should schedule a full CHKDSK to correct the problem.
To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in theMicrosoft Knowledge Base:
152734 How to Obtain the Latest Windows NT 4.0 Service Pack
Microsoft has confirmed this to be a problem in Windows NT version 3.51. Asupported fix is now available, but has not been fully regression testedand should be applied only to systems experiencing this specific problem.Unless you are severely impacted by this specific problem, Microsoftrecommends that you wait for the next Service Pack that contains this fix.Contact Microsoft Technical Support for more information.
Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.
Attribute entries within an NTFS File Record Segment (FRS) are labeled withan "instance tag" that must be unique for the attributes in a given FRS.The value for an attribute instance tag is generated when an attribute iscreated. Thus, typical instance tag values range from 0 to about 10 on mostfiles.
If an attribute is deleted and recreated, it receives a new instance tag.Each time a new instance tag is needed, NTFS increments a counterassociated with the FRS in question and uses the next previously unusedvalue. Thus, instance tags can grow without bound if attributes arerepeatedly destroyed and recreated.
For the vast majority of files and directories, the scheme described abovedoes not result in any problems because, once created, FRS attributes tendnot to be deleted and recreated. There is one scenario that is known to bean exception. If many files are repeatedly added to a directory and thendeleted from the directory in such a way that the "binary tree" thatindexes the directory becomes unbalanced, the "index root" attribute forthe directory is repeatedly destroyed and re-created. Because instance tagsare only 16 bits in size, this means that instance tags can be duplicatedafter a directory index has been rebalanced 65,535 times. Note that even ifinstance tags are duplicated, the directory will not be considered corruptunless, at some point, it contained a sufficiently large enough number offiles. Therefore this problem may be difficult to reproduce except indirectories containing large numbers of files.