On Windows 10 I was browsing one of three NTFS partitions on an external USB drive. After a reboot none of the NTFS volumes on the drive are accessible, as in "can't even run chkdsk/damaged file system/partitions are raw"-inaccessible. Each resided on its own primary partition.
My level: I don't know enough about internal (NTFS) file system structures to reason my way to what happened.
What I did before it happened
- Browsed to a directory I didn't have access to. Explorer offered to grant permanent access. I accepted. (I did this twice)
- I expected a 1 second operation, but it was taking forever (recursive, apparently)
- I failed to abort the operation by safely ejecting the drive, because Windows refused to eject it during alleged use.
- I asked Windows to reboot the machine, safe in the knowledge that it wouldn't do so before it was deemed safe, and that at worst I'd be left with a directory tree that I wouldn't have complete access to.
- Windows rebooted the machine in an orderly fashion. I did not force anything. In fact I was just hitting "Cancel" on the shutdown screen in order to inspect which app was preventing the shutdown when it simply proceeded with the reboot.
After the reboot all NTFS volumes on the drive had damaged file system structures according to Windows.
- Whatever I tried (rebooting, restarting the USB hdd dock, reseating the drive) I couldn't get them to read. Chkdsk refused to run from the explorer gui due to the drive being inaccessible.
- Connected the drive to internal SATA in another machine...
- ...and when starting Win 10 on that machine it immediately wanted to run chkdsk on the new drive, which then took more than an hour.
- The NTFS volumes are still not accessible in Windows (one is still raw, and the other two are 0 B size NTFS). The NTFS volumes are readable in Linux, but pretty much every single file has been moved into
- A non-NTFS ext volume on an extended partition on the same drive mounted and read just fine in Linux as far as I could tell.
- SMART data was all fine. Short self test ran with no complaints.
- The USB HDD dock has worked fine with the drive for years. There's no apparent defect in this dock after this incident either, but I'll use internal SATA going forward in this Q, just to be safe.
This gives rise to more than one question in my head:
On the one hand I don't understand how Windows managed to destroy all three NTFS volumes at once — I wasn't even interacting with or writing to the other two! Is there a plausible explanation for this? If I could understand that better then I could make more informed decisions about Windows/NTFS/USB drives in the future. I'm hoping this falls under the "please explain this to me" qualifier for questions on this site.
On the other hand, after reading some recovery answers here, I wouldn't mind knowing whether there's any point in...
...trying to make the volumes readable in Windows (or to just be content with that they can be read in Linux)? I would be more confident in knowing that Windows thinks the volumes are actually readable.
...attempting any more involved recovery on the two volumes that became readable in Linux after chkdsk moved all files to
found.000. I'm guessing "no" since chkdsk has performed writes when rescuing files?
...attempting applicable recovery on the "raw" volume assuming it was touched by chkdsk but still remained raw? I'm unfamiliar with the exact operations chkdsk performs while trying to fix a file system.
With this question I'm attempting to understand the circumstances of my problem, partly to avoid it in the future. I'm aware of the importance of backups and will be looking at what was/wasn't backed up in parallel with this Q. With this I'm hoping that we can focus on the part of the problem that's not related to backups.
Update, DMDE 2
I did a full scan on the first partition.
After reading about the various columns in the DMDE help it was still difficult to interpret the values. For instance, what does "Files", the %-bar graphs and "Start LBA" mean here? Intuitively everything but a start LBA at 2048 seems suspicious, but the field doesn't seem to be defined in the help so it's hard to say:
Looking closer it seems to maybe be zeroing in on a small NTFS disk image that was stored on the partition, meant for a 32 GB USB stick. That certainly would explain things about these column values and clear up some confusion. A head's up for future readers — things simply weren't complicated enough.