ChkDsk Questions

**holygamer** · 26-01-2016, 04:22 AM

I have a few questions.

1. I ran ChkDsk inside Windows and I copied the file. I could clearly see the names of some of my files that were corrupted. I then looked for the log in Event viewer via Windows Logs, Application, found file with source as "ChkDsk". I searched for the names of the files that were in the ChkDsk results from before and they weren't there. I noticed this line: "CHKDSK is verifying files (stage 1 of 3)..." but couldn't see stages 2 or 3 mentioned anywhere. It seems to be missing a lot of info. Why is the log incomplete? Same applies to running ChkDsk at boot, except I found the log under the source of "Wininit".

2. I have a Seagate Archive 8TB SATA III drive. Every day I edit several videos on the drive removing commercials then I cut and paste the videos into directories on the drive. After 1 year the drive is full and I backup to another drive. When doing that with Tera Copy (file copier) it said all files were copied but a few of the files were NOT as they were corrupt. So I ran ChkDsk within Windows which only took a few minutes or an hour (I forget). That seemed to indicate it repaired things although the few files were lost as they were corrupted. I thought that fixed things but soon after I just clicked on a directory on the drive containing videos and it said it was inaccessible and the file size was zero! So I ran ChkDsk at boot, it took 17 hours to complete and that seems to have fixed things. Why didn't it fix things when it was run within Windows? The within Windows scan said "Windows has made corrections to the file system" and 0KB was in bad sectors.

3. When running ChkDsk at boot or within Windows can I enter a command to have it save a COMPLETE log file somewhere? I don't want to have to find an incomplete log in Event Viewer.

4. What parts of the log should I be worried about with regards to files being lost? I see lines like this which are obvious: "Deleting index entry Live at the Apollo S03 E06.ts in index $I30 of file 1911. Deleting index entry LIE099~1.TS in index $I30 of file 1911."
But what about lines like the below? What do they mean?
Deleting corrupt attribute record (128, "") from file record segment 9895. Deleted corrupt attribute list entry with type code 128 in file 3596. Deleting orphan file record segment 9383. 6486 large file records processed. 0 bad file records processed. 0 EA records processed. 0 reparse records processed.

5. So the video in point 4 was corrupted. Before I ran ChkDsk I tried to play the video and it had a file size of zero and wouldn't play. But the original file name was still there so why did ChkDsk rename it to gibberish like this: LIE099~1.TS?

6. To run ChkDsk at boot I went into drive properties and ticked "Automatically fix file system errors" and "Scan for and attempt recovery of bad sectors". Is there a command for that instead?

Also my boot scan said "Windows has made corrections to the file system" "0 KB in bad sectors". Does that mean that there were NO bad sectors?
If so, does that mean I can get ChkDsk to run much faster by unticking "Scan for and attempt recovery of bad sectors". I only use the drive for 1 year so surely there's no way I would get phsyical damage (bad sectors)?

6. I'm really only interested in using ChkDsk to find out what files are corrupted and repairing them, etc. What command should I run for that?

7. I noticed by accident when using an FTP program that there's a folder called "found.000". Yet in Windows Explorer even when view hidden files is enabled I can't see that folder. Why can I only see it in my FTP program. It seems that folder contains several recovered files from ChkDsk.

Thanks

**peterb** · 26-01-2016, 09:55 AM

Chicks, like many tools, has a slightly misleading name.

Strictly it doesn't check the disk, it checks the file system structure and performs corrections to that.

The NTFS file system structure and the MFT that goes with it it quite complex, so check disk checks the integrity of the whole system, and then the integrity of the files, as far as confirming that file fragments are all there and referenced correctly.

It cannot determine if the data is corrupt because it doesn't know what the data was in the first place. Neither (IIRC) does it do anything at low disk level, the sectors it refers to are not low level disk sectors but file segments although the file system does try to allocate files within 512 byte chunks which corresponded to traditional 512 byte hard disk sectors

Allocation of data to hard sectors is determined by the disk itself, well away from the operating system and it can write that data wherever it likes on the platters, although obviously it will use the most efficient method to optimise read/write speeds.

I can't say why the chkdsk logs are incomplete. There will be command line switches for the various options, although they may not be well documented. Running something like chkdsk /? Or chkdsk /help may give a list of command switches. It's not a program I've used for a longtime!

**kalniel** · 26-01-2016, 10:08 AM

1. Not sure, did it finish or was it waiting for a reboot to continue?

2. Couple of possible reasons. Firstly the drive has to be unmounted for deep checks - windows can unmount the drive if it's not a system drive, but you have to let it. If you don't unmount then running chkdsk before the OS loads allows a deeper scan. Secondly correcting errors may result in other metadata being incorrect, requiring chkdsk to fix that too. While this mostly happens in the same pass, sometimes you need another pass.

3. Pass

4. Index entries aren't too bad - they should be updating to reflect the actual file situation. It's where it says something like recovered file information to FOUND that you mostly need to worry about lost files.

But those things you mention are likely consequences of bad file information/metadata in the first place.

5. Guessing that it means there's somewhere you can poke around in the file, while also making sure it doesn't overwrite anything and making sure the file name is in a format easily read.

6. Yes. chkdsk <drive> /r

Sounds like it didn't find any new bad sectors that scan. Still could be other errors though.

Why is there no way you could get bad sectors? Nothing's perfect.

6-the-sequel. chkdsk <drive>

Note if the file is corrupt it won't be repaired. If the file metadata is corrupt it *may* be repairable.

7. Yes. What explorer/windows shows you about files/directories is completely different what the actual files/directories may be. Go to the cmd prompt/powershell to see them.

**peterb** · 26-01-2016, 10:17 AM

Kalniels response was far more concise than mine, put to pick up on bad sectors, you could have bad sectors. The disk st manufacture may have bad sectors that are mapped out during drive resting before shipping out for sale. There is also a pool of spare sectors that are used if a bad sector is detected during the service life of the disk. The affected sector is marked as bad, and the internal disk pointers map in a spare. All this is transparent to the operating system.

**Corky34** · 26-01-2016, 11:12 AM