0

So I have two 3TB HDDs, one being the backup of the other, almost full (containing mostly videos, TV documentaries and whatnot), with no hardware issues (SMART parameters are all fine). I plugged one of them through an Akasa Integral external enclosure, in USB 2.0, to my laptop PC running on Windows Vista. The HDD was erroneously detected as being 746GB, and a CHKDSK analysis was recommanded, supposedly to avoid data corruption ; I didn't think twice and let it run... but then, I quickly discovered that it had severely corrupted the file system : a comparison with WinMerge showed that more than 100GB of files were damaged to a varying degree (for some of them only a cluster had been replaced or overwritten, some were entirely wrong and unreadable, for some of them the begining was in fact the begining of another file of any other type – for instance a MP4 file appeared to have a MHT header, or a TXT file appeared to be a directory index, etc.). Doing another CHKDSK analysis on my desktop PC running on Windows 7 with the HDD directly connected in SATA did not repair those files. Luckily I did not lose any important file as I had a virtually complete backup, but still, I'd like to understand what happened and why.

Now, what happened here ? Is it a known issue ? Could it be due to a limitation of the USB controler of that external case ? Normally Windows Vista is supposed to deal with 3GB HDDs just fine (as opposed to anterior versions). I think (but I'm not sure) that I previously used that same external case to plug a 3TB HDD to that same laptop in eSATA with no such issue.

And can someone help me understand how CHKDSK could corrupt the file system, although it's precisely supposed to ensure that it stays consistent and perfectly operational ? What did it do to the MFT to get that result ? Did it consider that any cluster beyond 2TB, was invalid and had to be un-allocated ? Yet I couldn't find any particular pattern with regards to the location of the affected files : most of them had been added recently, but some of them were older, having been copied in bulk when migrating from a smaller capacity HDD ; some of them appeared to be at the end, some at the begining, way before the 2TB mark (I used WinHex and R-Studio to find out the locations).

Any hint would be appreciated, thanks !

GabrielB
  • 845
  • 8
  • 24
  • The SATA to USB controllers in external enclosures do need to support a given disk volume, and I believe that it must also support the partition type. If the enclosure does not have a controller that can handle the disk you installed, it may be presented to the OS as something entirely different. As for chkdsk, understand that it is a Filesystem utility primarily, so it starts with the NTFS filesystem metadata and then evaluates how well the disk matches what the metadata describes. if the geometry of the disk is misrepresented, then it has no hope of functioning correctly. – Frank Thomas Oct 13 '17 at 04:03
  • @FrankThomas Wow, thank you for this very quick reply ! I haven't made further testing with this external enclosure and a 3TB+ HDD connected in USB, fearing that it might screw up something else. But is there a way to understand what happened exactly, how CHKDSK did proceed ? And, based on that knowledge, would it have been possible to recover those files if I had had no backup ? (I'm pretty sure that it already happened to someone...) – GabrielB Oct 13 '17 at 04:14
  • well, generally, data-recovery is affected by the physical state of the disk, whether the filesystem metadata is still available and accurate, and whether the data in question has been overwritten. the other concern is that you need a volume to restore to, you absolutely cannot recover lost data to the volume you are recovering from. period. I would get another volume (don't use your backup volume, you may still need it), image the current disk to it as a backup of your state. Then I'd reinstall the disk as it was before the enclosure fiasco, and try chkdsk again. – Frank Thomas Oct 13 '17 at 04:18
  • if chkdsk can't fix it, you will probably have to resort to undelete utilities like recova or easus. if those can't recover the data, you will have to try file-carving utilities like photorec, but unfortunately they only work for specific file types, and without filesystem information, the filename and folder location are lost so you end up with a directory filled with random named files with no idea what they are. there are never any guarentees with data recovery, so don't take risks or cut corners. keep your backups safe. – Frank Thomas Oct 13 '17 at 04:24
  • In this case some of the corrupted clusters have been overwritten (by directory indexes, or what appears to be system files) ; that would not be recoverable. But some of those files, as I explained, appeared to be wrongly indexed, and correspond in fact to different files on the same volume, with no other corruption to the data stream. Would there be a way to systematically repair the filesytem in such a case, or at least repair the individual files ? Or is that an impossible task ? As for CHKDSK, there should be a big warning somewhere, to prevent stuff like this from happening... – GabrielB Oct 13 '17 at 04:36
  • [Tried to use my 3TB drive in a USB enclosure, now reports only 746GB even internally](https://superuser.com/q/281108/241386), [3TB hard disk displayed as 746GB](https://superuser.com/q/608298/241386), [Cannot use more than 746GB on 3TB Drive that is reporting 2TB free](https://superuser.com/q/344662/241386) – phuclv Oct 13 '17 at 05:00
  • Maybe [*Why is my USB drive showing corrupted data when plugged as an internal SATA drive?*](https://superuser.com/a/985330/432690); reverse situation, the same cause? – Kamil Maciorowski Oct 13 '17 at 06:17

0 Answers0