Jump to content

corrupted disk partition, Start of MFT rotated 16 bytes


Recommended Posts

I will try to address your last post bit by bit so I will make more than one post.

attached is the first 7fff bytes from the start point of the first MFT. You will observe that the skewing only affects the first cluster of the MFT, and that the last line of the last skewed entry appears to be missing. This is why I suggested the whole block has been rotated 16 bytes. There is a spare last line now right at the beginning. I dont know enough to say whether it is a sensible last line but it seems to have similar format to other records. Saving what I have attached without the first odd line and then examining it, the records appear to make sense as the start of the MFT. I havnt so far had time to examine more of the MFT further on to see if it appears valid. I recognise that there may yet be other damage elsewhere to the file system, even if this is basically the correct MFT.

Link to comment
Share on other sites


You will observe that the skewing only affects the first cluster of the MFT, and that the last line of the last skewed entry appears to be missing. This is why I suggested the whole block has been rotated 16 bytes. There is a spare last line now right at the beginning. I dont know enough to say whether it is a sensible last line but it seems to have similar format to other records. Saving what I have attached without the first odd line and then examining it, the records appear to make sense as the start of the MFT.

Yep :thumbup , as you say.

Point is that you should read in that file "FILE0" at addresses (relative):

0

1024

2048

3072

but you don't, whilst starting at 4096 everything seems fine again.

BUT then, if it is not a "shift" WHY the $MFTmirr is also "rotated"? :unsure:

However, test to do is:

  1. Copy just the first 4096 bytes of the $MFT to a file.
  2. Make a backup copy of this file as-is.
  3. Modify the file by inserting 16 bytes at the end of the file, then cut first 16 bytes of the file and paste them over the 16 bytes appended.
  4. Check twice and thrice that the file begins with "FILE0" and ends with (in your case) 56 04 and is 4096 bytes in size
  5. Save the modified file, then copy and paste it's contents over the $MFT on disk.

You may need to disconnect/reconnect the disk and/or re-boot.

See if the filesystem "re-appears".

IF everything is fine and you can get back your files, get them :), I wouldn't risk to run CHKDSK on that volume unless you have (as you should have) a "dd like" or "forensic sound" image of it.

Something else that you may want to do BEFORE is to save the whole $MFT "as is", "fix" the first 4096 bytes as above, then analyze it:

analyzeMFT

http://www.integriography.com/

jaclaz

Link to comment
Share on other sites

Ah, youre getting ahead of me. Have to do other things as well. Attached is first cluster to be found at MFT and at MFT mirror addresses. I havnt checked if they are literally identical. I dont know how big the backup of the MFT is supposed to be? I can definitely say that the mirror copy does not extend past this first cluster. There is some other entirely different data which follows it. Is it supposed to be bigger than that?

I hesitate to simply roll the data and put it back in case there is some other problem. I am very nervous about self-repairing file systems which might turn out to be self screwing once the system decided it has some sort of MFT.

Still dont understand what might have happened?

mft mirror and main first clusters.zip

Link to comment
Share on other sites

Ah, youre getting ahead of me. Have to do other things as well. Attached is first cluster to be found at MFT and at MFT mirror addresses. I havnt checked if they are literally identical. I dont know how big the backup of the MFT is supposed to be? I can definitely say that the mirror copy does not extend past this first cluster. There is some other entirely different data which follows it. Is it supposed to be bigger than that?

Right again :), though not actually related to "clusters", the $MFTmirr is the first 4 record of the $MFT, i.e 4 x 1024= 4096, which casually is also the size of the cluster on your NTFS volume:

http://www.ntfs.com/ntfs-system-files.htm

Still dont understand what might have happened?

Same here. :(

The difference btween the $MFT and the $MFTmirr is probably not so casually in the last two bytes of the "16 shift", i.e. 56 04 vs. 01 00.

Personally (and judgng from the other "last bytes" I can see) I would vote for 56 04.

But what :w00t: can have caused this is still a mistery. :ph34r:

jaclaz

Link to comment
Share on other sites

ok i decided to be bold. winhex is a demo and wont write so with tiny hex I edited the first mft to rotate it back in place. I dont know if what I did next was a good idea or bad, but I then started winhex to see what it would show of the sectors I had edited to check them. It did not complain about a bad format.

I noted the edited sectors were ok, except that the last but one byte of the first entry was wrong by 1. I scrolled up and down a bit, and noticed that at i did so, this number was changing in all the early MFT system records. I closed winhex and called up a new view of the MFT with tiny. Sure enough, it had changed again.

So having concluded whatever had happened had happened, I went back to winhex and had a look at the backup MFT. I did not edit this, but it had now updated by itself to reflect the updated main MFT.

I tried windows explorer, which still said drive G was bad.

I rebooted. Windows asked to run chkdsk on G and I told it no. Explorer still said G was bad. Reopened winhex, which now lists directories and files on the bad partition. It will only recover small files (demo version!) but it did this and copied some to a different drive. I dont know if they are valid.

I ran Chkdsk on G in non-write mode. It said ntfs, seagate750g (the name I gave the disc), stated 'file verification completed'. Then started throwing a list of 'deleting orphan file record segment' messages. This terminated after about 100 of these saying 'errors found. Chkdsk cannot continue in read only mode'.

Dont know what you make of that? did it stop listing because that was all it found, or because it reached a maximum it could process without writing changes?

I reckon I need a program which will pick off the files I am interested in and copy them before letting chkdsk loose on doing its deletions.. Any suggestions?

Edited by damocles
Link to comment
Share on other sites

I reckon I need a program which will pick off the files I am interested in and copy them before letting chkdsk loose on doing its deletions.. Any suggestions?

I would try first thing:

NTFSWalker:

http://dmitrybrant.com/ntfswalker

and ScroungeNTFS:

http://thewalter.net/stef/software/scrounge/

Before going to Commercial apps.

jaclaz

Link to comment
Share on other sites

ntfswalker gives an error and says the file system is corrupt. Im not sure what scrounge generates?

Still, you should dd the partition and THEN try running chkdsk /F on it.

Most probably the drive will be revived :yes: , but why taking the chance? (Or take the chance of NOT running it and risk not being able to recover the data, or do so in lots of time or with complex procedures?)

Attempting a (possibly partial) recovery on a filesystem that can possibly be revived by a simple chkdsk /f seems to me like making one's life more tough than needed.

Comeon, besides the fact that you should ALREADY have had a backup, with today's hardware prices, you should get a 640 or 750 Gb disk and make the copy, if you really care about the data.

The usage of scroungentfs seems clear enough to me :unsure::

http://thewalter.net/stef/software/scrounge/win_usage.html

But in any case, assuming that scroungeNTFS will recover each and every file on the volume WHERE do you think to store the recovered data?

Since NTFSwalker is a no go, try using dmde:

http://softdm.com/

jaclaz

Link to comment
Share on other sites

I agree about the price of hardware. I fixed the problem originally by buying a new disk and reinstalling. Not that this is a trivial thing to do, because it certainly isnt. QUite honestly I dont think there is anything irreplaceable on the disk. Most of it has been replaced already or could be. I said already I am interested in fixing it for the sake of fixing it.

I dont understand what you mean ''dd the partitions''. (is it meant to be a link which went wrong?). I think you are right, chkdsk will be an eventual step. However I'd remind you this started with a rolled cluster, which remains unexplained. Virus anyone? Or was it a genuine windows screw up?

Theres probably 300 Gb of free space here for dumping files, but again I dont want a program which will indiscriminately recover everything, 99% of which is certifiable junk.

I dont see quite what information scrounge would pick up and what it would do with it? There seems to be no way to choose, so presumably it is going to dump everything (an intedeminate 100's Gb), somewhere, Will it respect the existing directory structure, which is readble to some things, or just dump stuff somewhere?

This is becoming a bit of a software shopping expedition. Thanks for all the suggestions.

Link to comment
Share on other sites

I dont see quite what information scrounge would pick up and what it would do with it? There seems to be no way to choose, so presumably it is going to dump everything (an intedeminate 100's Gb), somewhere, Will it respect the existing directory structure, which is readble to some things, or just dump stuff somewhere?

Yep :), that's the general idea.

Results depend on how "sound" is the underlying NTFS, so cannot say what would happen in your case.

This is becoming a bit of a software shopping expedition. Thanks for all the suggestions.

DMDE usually can find (and you can save from it) single files, but it is normally a long and tiresome project, doing one-by-one.

The general approach is recover (automatically) "everything", then discard whatever you are not interested in.

"dd" is the traditional sector-by-sector or "forensic sound" disk imaging program.

If you have a "sound" filesystem you can use shortcuts, but in the case of a corrupted filesystem it is vital to image "everything", (meaning each and every sector) even what is not indexed or accessible by the filesystem.

A list of programs is given here:

http://www.msfn.org/board/index.php?showtopic=100299

The one I normally use as it does what I usually need is dsfo/dsfi (part of the DSFOK package):

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

but there are a few windows ports of the original dd.

It is possible to write a small batch that will copy only the actual non-zeroed sectors to a sparse image (a sparse file on a NTFS volume is a file that has a "target, nominal" size but that will occupy on disk only the actually non-zeroed sectors) but the imaging would take a looong time and the actual occupation on target depends on the actual amount of data in the original volume (and please take note hat in this case also deleted data "counts").

Only you can say how "filled" the original volume has ever been.

If you have nothing to actually lose, simply run chkdsk /f and see what happens.

An alternative could be if you are interested only to a small number of files, and you know which type they are to use a file based recovery approach, PHOTOREC is excellent at it, if the original volume was defragged properly you have near 100% probabilities of recovering everything:

http://www.cgsecurity.org/wiki/PhotoRec

If you are willing to fork from a few bucks (which you seem like not, otherwise you would have already shopped for a 640 or 750 Gb disk and imaged the drive properly), this Commercial app normally can recover most things from a NTFS system:

File Scavenger

http://www.quetek.com/prod02.htm

but there are many other tools, bothfreeware and commercial that you can try.

In italian there is a proverb "Avere la botte piena e la moglie ubriaca" that could translate roughly to "Having the wine cask full and the wife drunk", that seems like applying to your approach :whistling:.

Summarized:

  • you have a problem (or a supposed) one
  • you come here for help/suggestions
  • you are told that steps are 1.,2.,3.
  • you do them
  • you are then told that following steps are 4.,5. and 6. (safe) or 7.,8.,9. (probably working but with a percentage of risk)
  • you go idle thinking about steps 10.,13. and 18. (since 4 to 6 cost money and 7 and 9 are risky, and you don't fancy 11., 12. and 14. to 17. :w00t:
  • my good friend Mr Spock would define the above illogical :ph34r:

The "right" thing to do is to image the drive first and then run chkdsk /f on it.

The second "right" thing to do is use scroungentfs and/or ntfswalker and/or dmde and/or photorec and/or any Commercial corresponding utility/tool and recover the files from the volume, and then run chkdsk /f on it.

The third right thing to do is take some risks and go ahead and run chkdsk /f on it.

Anything else, given the amount of limits (of disk space and money) you have though perfectly possible will resolve in eiher a lot of time spent with dubious results or in no results and no way back.

But still, the only thing that you should have learned - which, judged from the fact you didn't already bought a 750 Gb drive - (and I will probably loose my voice shouting it shortening my fingers typing it), is that the BEST approach to data recovery is NOT needing to perform it, which you should read as BACKUP!, NOW! ALL your data! :realmad:

Murphy's Law is ALWAYS around trying to prove itself right once again, the fact that you have already bitten by it doesn't mean it won't happen again, and it may also happen very soon. :(

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

No need to get over excited. everything is fine. I am the sort of person who has a stack of old hard drives going back 25 years. Even the ones which definitely died are still there. you never know when they may be useful. This particular drive has been sitting about awaiting attention. The original issue was resolved by buying a new one and restoring everything currently needed to it. There may be some stuff still on this one which is irreplaceable, but probably not which is essential. Things just collect on discs.

I had two duff seagate discs and I have posted on here about both of them, and received suggestions about both. Some suggestions about seagate's business model too. Thanks for all that. It was useful and appreciated.

In my first post here i said I had a rotated MFT. I thought this rather odd, and I still do. No one has come up with any suggestions how it happened, which in terms of stopping it happening again might be useful. I disappeared a bit yesterday because I was putting into practice the suggestions. DMDE may or may not be the best program but it did what I wanted, which was to hunt through the directories looking for the important stuff and copying it off. This manual process was necessary anyway, to separate out what was useful. Today I turned on the computer while doing something else and not thinking about it, so when I cam back it had unilaterally started running chkdsk. This took a little while and threw out loads of messages. At the end of it, windows has stopped complaining about the disk and superficially it seems to be back in business.

Clearly a rotated cluster was not the only thing wrong with the disk. It may have suffered from windows attempts to read it. I found the fact that windows was updating the control files even while it claimed the partition was unreadable a little disturbing. there is now a collection of recovered files: as is usually the case, generally small and mysterious.

Link to comment
Share on other sites

I am the sort of person who has a stack of old hard drives going back 25 years. Even the ones which definitely died are still there. you never know when they may be useful.

If you are also in DIY/Electronics, I can give you a nice idea for one or more of those:

http://www.ian.org/HD-Clock/

In my first post here i said I had a rotated MFT. I thought this rather odd, and I still do. No one has come up with any suggestions how it happened, which in terms of stopping it happening again might be useful.

Yep, that's the problem.

Common sense and experience (and ONLY that, i.e. NO evidence whatsoever to backup this statement :ph34r:) tells me that it has nothing to do with actual hardware, and it is/was a software problem, still of UNKNOWN origin.

Clearly a rotated cluster was not the only thing wrong with the disk. It may have suffered from windows attempts to read it. I found the fact that windows was updating the control files even while it claimed the partition was unreadable a little disturbing. there is now a collection of recovered files: as is usually the case, generally small and mysterious.

I suspect that the rotated cluster was the "last step" of something else that caused *some* kind of corruption - probably in RAM or in the filesystem driver, and then the "rotation" of the cluster which in turn produced more filesystem corruption. (but again I have nothing to support this claim)

DMDE may or may not be the best program but it did what I wanted, which was to hunt through the directories looking for the important stuff and copying it off. This manual process was necessary anyway, to separate out what was useful.

Rest assured, DMDE is :thumbup one of the best programs around, only since it is VERY good and has LOTS of options is not something that I would advice normally to an unexperienced user, I mean if simpler tools can get the result, why using a more "advanced" one.

Anyway, happy that the problem is now solved :) and I guess I can count you as another happy bunny:

http://www.msfn.org/board/index.php?showtopic=128727&st=10

(though we won't probably ever know WHAT originally caused the problem :unsure:)

If you plan to use that disk under XP please note that it is still "old school aligned" (since it was evidently formatted form a "standard configured" Vista) and this may - in a limited number of peculiar partitioning schemes (NOT in the one you are currently using) to lose a partition, see here:

http://www.boot-land.net/forums/index.php?showtopic=9897&hl=

jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...