I ran chkdsk on a drive and when it got to stage 4 (verifying file data), this message appeared for some files:
Windows replaced bad clusters in file ######
of name \path\filename.ext
Does this mean that these files are now corrupt? I'm mainly concerned about ISOs and executables. Unfortunately, I don't have hashes of them so I have nothing to check their integrity against after chkdsk finishes running.
If it's relevant, this is a mechanical hard drive, a 2TB Western Digital Green.
The answer is, it depends. the file was at least in part occupying a bad cluster, which in effect corrupted the file. chkdsk reallocated the sector (pointed that address to a not-bad location on the disk surface) and attempted to copy the contents of the bad cluster to it. there is no guarantee however that the data in the source cluster could be fully recovered to the destination. if it was, your file is intact, but if it wasn't possible to recover the data completely and accurately, there will have been some corruption.
unfourtunately, without a baseline, there is no way to tell.
Does this mean that these files are now corrupt? The files were corrupt and Windows was able to repair the file Unfortunately, I don't have hashes of them so I have nothing to check their integrity against after chkdsk finishes running. I'm mainly concerned about ISOs and executables.
You will have to find those checksums depending on the file that chkdisk repaired shouldn't be hard. In the end corruption of a cluster was detected. You should restore the file from your backup source.
If it's relevant, this is a mechanical hard drive, a 2TB Western Digital Green.
You should start to backup your data more often so you have something to compare checksums too.
If the file was a system file you should run sfc /scannow to verify the integrity of Windows.
Often, a file is allocated clusters on a disk but is not necessarily storing meaningful data in those clusters. For example:
In such a case, the files will usually contain some meaningful clusters, and some clusters which contain unrelated data you have deleted in the past, such as files marked by the filesystem to be overwritten. So, sometimes even if a file is technically corrupt, you may be fortunate that the integrity of the file is not compromised.
However, it would be a good idea to check the integrity of the file with a tool that understands the specific file format, where possible. Such tools exist for most forms of disk image, database and media file.
In a case like this, one could use an hexadecimal editor and search if there is an abnormally long sequence of 00s interrupting an otherwise complex data area. Typically, if at some point you see a multiple of 512 bytes of blank data, starting at a 512 multiple offset relative to the begining of the file (sector boundary), in an area where there should be (seemingly) random characters (if it's a binary file), or a readable sequence of characters (if it's a text file), then you can be pretty sure that some corruption has occured.
Of course, for that to be manageable would at least require a least of the bad sectors' LBAs, it's not practically possible to check every single file like this. The best course of action if there are bad sectors on a storage unit is to first clone it with a suitable tool (ddrescue is often recommanded), then run CHKDSK or any other tool designed to attempt an in-place repair, which can succeed or fail but will never explicitly report what the actual outcome was. Otherwise, the only reasonable way to detect such errors is to be attentive to any kind of glitch when later reading / playing / running the files that were stored on that device, and then check them with the method indicated above.
