Thanks for your reply.

I now see that there was something which wasn't stated in this thread - which is this appears to be the same issue that you described in a previous thread:

http://forum.hddguru.com/mybook-lost-file-system-t17949.html

where you said:



For some sectors on that drive, it is already too late to copy them - that is the definition of a pending [reallocation] sector; they are already unreadable. By using the information from that previous thread which I found, my concern that there is evidence of another underlying problem, has been confirmed.


I'm fully aware of R-Studio However those checks still do not confirm that the files are usable (file contents have not been tested, even if size looks correct - file contents could be wrong, e.g. if the MFT is corrupt).

For this reason, and before doing anything more with the original drive, I would ensure that I had at least one complete image of that drive, and not trusting just the files which one recovery program thought was correct - but I see that you are following a different plan, so I won't waste your time with more suggestions from me. I wish you good luck.

Yes, It can be but, I meant I have played some music files and opened the pictures etc.
You don't waste my time, I am considering every suggestion, although whats the point to make an exact image of the drive if its corrupted?

I agree with you on this one. You have back your data on another HDD. You know that this file system is totally screwed up and the WD is not such a wonderful disk on this one. You also took a long time to run the recovery progam and save all your work. If you have verified it is working then you do not need to do it a second time.

What you can try to do now to repair your WD is download from here MHDD. Try and scan it. But it will not work if it is still in the external enclosure. You will have to mount it to your MB to do this one. You can run a scan with MHDD and see what is really going on in this disk with bad sectors on it. It can zero fill the disk and you can reallocate all your bad sectors on it.

If this one is not going to work for you then I would consider to leave this disk and send it back for RMA on it and get a new one. Buy a new external enclosure for your other HDD that you have put all your data on and go from there.

There are times when it is time to move on and not fix a disk that broke. Sometime there is a reason behind it and a warning to you on it. I would say you are lucky to have all your data off this and safe on another HDD. You can always try to RMA this drive and see what WD will do for you on it. Maybe this is a better move all the way around than playing with it after finding out that the file system is messed up, cound be from some internal problems on the drive. These drives are not the best in the world and are well known for their problems. We too have many of them coming in for recovery work and a good percentage of them is for heads on it. Some fail in no time at all on these drives. That is all that I can offer to you.

_________________
Iorana Haraharaini

I see. Thanks for your detailed reply.

Of course, I wont spend too much time to fix it, I was only looking for some background information what can be done.

Btw. I will never buy such crap with the encryption, which can not be disabled before using a HDD and connected internal through SATA.

OK, but it does waste my time making more suggestions and explaining them, if a different plan is already being followed


The point is that then when you have an image, you are not relying on just what R-Studio recovered so far. You can later have the opportunity to use a "master image" for anything else e.g. trying other recovery software, or manual filesystem editing, or fast copy onto a new drive etc.

In DR, it is a "best practice" to get an image while the drive is working, in case the drive fails at any later time. Right now if that drive failure happens, you would be left only with the files collected by R-Studio - do you completely trust that?

Either:

(a) you are 100% confident that the recovered files from R-Studio are all that you need, because you have checked and they are all perfect (in which case this is not about DR any more, but is an exercise where you can learn about NTFS) - this thread is already taking much longer than following the suggestions you got at the beginning of the thread, to just copy the data from the R-Studio "recovery" ;

or

(b) you are not 100% confident that the recovered files from R-Studio are all perfect (and that is why I suggested that you get an image of that drive now, in case it fails catastrophically before you can recover the files again later, in a way which you are confident is 100% perfect).

I think the answer is (b); but if you believe your answer is (a) then as I explained, this is no longer DR if you really believe that you have already recovered the data - and we already have the indications which you mentioned in the first thread, that the drive has a problem and so cannot be trusted. Since IMHO that drive cannot be trusted, I would get another drive instead (either RMA that one, or buy a Hitachi).

As I said before, I wish you good luck.

I see your point of view. You are right. One question then, when can I be 100% confident?!

They appear identical. You can make the comparison easier by copying the sector data to a file, and then using the File Compare command in a Windows DOS box, ie ...

fc /b sector_63.txt sector_1952138474.txt

The next sectors to compare would be the $MFT starting cluster (0x000C0000) and the starting cluster of the $MFTMirror (0x0745B44A). The volume has 8 sectors per cluster, so the logical starting sectors numbers are 0x600000 and 0x3A2DA250, respectively. Add 0x3F (= 63) to the logical sector numbers to obtain the physical LBAs. This places the $MFT and $MFTMirror starting LBAs at 0x60003F (= 6291519) and 0x3A2DA28F (= 976069263), respectively.

Hopefully my calculations and reasoning are correct. If so, then you should see the beginning of the $MFT metadata at the abovementioned sectors. Examine the next 7 sectors to see the entire cluster.

_________________
A backup a day keeps DR away.

FYI, I use The Starman's Realm as my reference for MBR and boot sector related information:
http://mirror.href.com/thestarman/asm/mbr/NTFSBR.htm

For hexadecimal-to-decimal conversions, and vice versa, I use Google's calculator, eg ...

http://www.google.com/search?q=0x3A2DA28F+in+decimal
http://www.google.com/search?q=6291519+in+hex

_________________
A backup a day keeps DR away.

Thanks for both replies, I will check this issue and get back.

The $MFTMirror if your calculations are correct for starting sector (976069263) all 7 sectors are filled with 00-s!
How does this effect the filesystem/partition recognition by windows?

Btw. CHKDSK shows Volume Bitmap is incorret, windows found problems with the filesystem (obviously )

But there is a problem with the security descriptors also. I cant find a proper english message but it tells me, that the security descriptor of file (5) is missing or invalid.

Maybe it makes sense to you, considering the informations together.

What does sector 6291519 look like?

BTW, a cluster consists of 8 sectors (the starting sector plus the next 7). Just to confirm, are you saying that sector 976069263 plus the next 7 sectors contain all zeros?

_________________
A backup a day keeps DR away.

This URL explains the $BITMAP:
http://whereismydata.wordpress.com/2009 ... he-bitmap/

More NTFS info:
http://whereismydata.wordpress.com/cate ... forensics/

_________________
A backup a day keeps DR away.

@disaster, what you want is "something" that could RECONSTRUCT AND FIX THE FILE SYSTEM on THE DESTINATION DRIVE, without affecting data and for free, right ?

I will attach the pic soon.Yes, thats right.

Sorry, this is weird. Unfortunatelly I did not make a log previous, but now the sectors are not full with zeros.. I dont understand.

6291519 (see attached)
20 zeros
21 not empty
22 zeros
23 not empty
24 zeros
25 not empty
26 zeros

976069263 same as 6291519
64 zeros
65 same as 6291521
66 zeros
67 same as 6291523
68 zeros
69 same as 6291525
70 zeros

You stated that you ran CHKDSK. If you ran it in repair mode rather than readonly mode, then perhaps it rebuilt the $MFTMirror.

Notice that at offset 0x00C0007EF2 there is a unicode text string, "$MFT". I believe you should find similar strings in the other sectors corresponding to other metafiles, eg $BADCLUS and $BITMAP.

See http://en.wikipedia.org/wiki/NTFS#Metafiles

BTW, I suspect that when CHKDSK verifies the integrity of $BITMAP, it would do so by taking a walk down the MFT and determining the clusters occupied by each file. It would build its own bitmap of free and occupied clusters, and then compare it against the $BITMAP maintained by the OS. They should be identical.

_________________
A backup a day keeps DR away.

I have ran it without any parameter, just to see what it detects. I did not want to run it in repair mode yet. Only when no other option helps, because it could mess up everything (maybe).

I think I've reached the limit of my knowledge. Sorry, I can't think of anything else to check.

_________________
A backup a day keeps DR away.

finally i deleted the partition again, recovered with easeus and ran chkdsk /f, and the partition is ok again

thanks for the help