@fzabkar
Quote:
AISI, the partition table and NTFS boot sector seem OK. I don't know where TestDisk is getting its information from.
Isn't the “Last Cyl 1023” value erroneous ? If I'm counting correctly, it corresponds to 16450560 sectors, or about 8GB...
How would you explain that some softwares (R-Studio, WinHex, MyDefrag, DMDE) deal with it fine, while others (Windows Explorer, CHKDSK, Defraggler) choke on it ?
DMDE can also display the whole file tree instantly, but reports an error for (at least) 3 MFT entries, saying “ERROR Attribute Offset” :
Attachment:
ST2000DM001 Z4Z0T7LY DMDE Root.png [ 112.93 KiB | Viewed 28939 times ]
[FLASHBACK]
I've had a similar issue about a year and a half ago where a 1TB external USB HDD had its single partition no longer recognized, and CHKDSK could do nothing. In that case, R-Studio couldn't readily list the contents, although it probably could after a complete scan (I kept a few screenshots of the case but don't remember all the details) ; DMDE (that's the one time I've used it extensively so far) could list the contents after a full scan ; but in that case WinHex couldn't : it reported “unexpected data” where the MFT should have been and wasn't able to proceed further. When opening the whole drive with WinHex, I noticed that the MFT appeared to be shifted by 1 sector, relative to the value indicated by R-Studio (it was supposed to start at sector 6291456 + 2048 [partition offset] yet the actual begining was located at sector 6293505 – I still have no idea how this could happen spontaneously). So I first extracted the whole contents to another drive with DMDE, made a backup of the first 5GB with WinHex, then attempted to shift the whole MFT up by 1 sector ; then I ran CHKDSK again : it failed as well (said that some critical files in the MFT were damaged). Then I restored the backed-up first 5GB, and this time attempted to just copy the first sector of the MFT (which points to the MFT itself) onto the sector before, which was supposed to be the actual start of the MFT ; then I ran CHKDSK again : and it worked ! It was able to proceed, it did fix the filesystem, and the whole contents were accessible again. Then I thoroughly compared with WinMerge the in-place contents with the contents extracted with DMDE, everything matched.
[/FLASHBACK]
In this case (the current issue with the 2TB HDD), when examined with WinHex, the MFT seems to be at the right place (6291456 + 63), but what should be MFT records for $MFTMirr, $LogFile and $Volume (respectively MFT records 1, 2, 3 – just the ones for which DMDE reports an error) are filled with “FF” values (“ÿ” in ANSI), there are 3072 “FF” bytes, then MFT record 4 is fine ; MFTMirr (located at sector 16 relative to the partition's start) looks just the same (first record fine, then three corrupted). What does it mean, how could it happen, and how can it be fixed “cleanly” ? How come CHKDSK can't deal with just three corrupted MFT records ? Perhaps it precisely needs to access those three particular system files and can't, since they're no longer correctly referenced ? How can WinHex / R-Studio / DMDE locate those files and display their metadata accurately without the correct data from the MFT ? What is likely to happen if I just copy MFT records 1-3 from
another drive ? (Some values won't match but maybe CHKDSK will be able to fix them... it's not that “clean” though, I'd prefer to know exactly what I'm doing !
)
Side question : if I remember correctly, having the partition start at sector 63 is the default value when a drive is formatted with Windows XP, and means that the partition is not properly “aligned”, relative to 4096 bytes clusters ; could it be a problem with a 2TB HDD, or is it relevant only for SSDs ?
@Spildit
Spildit wrote:
jermy wrote:
clone the drive
AGREEE !!! DO IT NOW !!!
And stop messing with the original one ...
We don't even know if the drive is ok ...
You should check S.M.A.R.T., clone the drive with hddsuperclone and then run a full MHDD/VITORIA scan on the surface !
Well, I already checked S.M.A.R.T. with HD Sentinel (first thing I did after the fall). If there were any problem, wouldn't HD Sentinel report it ?
What is the advantage in testing with MHDD/Victoria instead of HD Sentinel ?
Cloning seems overkill in this particular case : I already tried extracting a few files with R-Studio (which also has a SMART analysis pannel and reports the drive as “GOOD”), it worked flawlessly, I could just extract all files like this.
Regarding the fall : I have a 2.5" Samsung drive which once literally
flew across the room (I had forgotten that it was on top of a bunch of papers which I removed hastily during a phone call or something like that...), and fell on hard floor from about one meter in height, while unplugged, and is still working flawlessly, probably more than two years later (I'm using it as a backup for my brother's computer and external HDD). I'm not saying that such a fall can
never affect the physical integrity of a HDD, but apparently it can happen with no dire consequence. But if things go wrong, I'll have been duly warned !
@dick
Quote:
Why is Dmde showing the drive as a raid volume?
Not sure, but all the others are as well, even though none of them are actually configured as RAID. Must be related to the motherboard's storage configuration. It's an Asus Maximus Hero VIII.
FAQ
Search
Login
Register
HDDGURU FILES
; but why are you so adamant about an impending hardware failure, when there's no sign of this whatsoever right now ? (Well, except for the fact that this particular range of drives appears to be doomed right from the begining... but aren't we all ?