damocles

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.

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.

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

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?

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

well that was a bad start. attachment disappeared.. first 7fff at MFT position from duff ntfs partition.zip

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.

well here you are. Didnt think about what it meant, just followed the steps you describe, The results are exactly the same. Skewed records. Perhaps I should make clear that with winhex when examining the MBR I used a window opened on the physical drive, and when examining the partitions was using a screen opened on that partition. The program is automatically using addressing relative to the partition start. I think this is exactly how it is designed to be read with regard to the information in the partition boot sector. The screen in front of me right now states offset 00c0000000 logical sector number 6291456, physical sector number 6293504, cluster number 786432. (the skewed MFT) These seem to be logical rather than physical clusters. (though I suppose, what other sort could they be, since the cluster size might vary on different partittions?) if I scroll the window to offset 0, it then reads logical sector 0, physical sector 2048, cluster 0 and shows me the partition boot sector. physical drive 1 sector 512002040 and 62935041.zip

was just faling asleep, which is not a good time to do hex arithmetic. However have woken up a bit. Using winhex I get a hex listing of the partition content which it gives addresses simply described as 'offset', counting upwards from 0. At 0 I see the ntfs boot record, which seems correct. At offset 0C000000 which is equivalent to the start of cluster 786432 or sector 6291456, I get the skewed record which I posted earlier, which you have probably already looked at. At sector 6293504 I get a string of file records, which is not surprising because if my assumption is correct, this would be somewhere within the MFT. winhex also has a record translator which presents MFT entries in a legible form. This claims that the record at sector 629504 is a file called A0003348.dll. i have no idea what that might be, but the entry seems reasonably valid. At sector 6291464 i find file $attdef, at ...466 i find '.', at ...468 i get $bitmap...470 i get $boot. The program will not translate the sectors at ...456 ...458...460...462 because although they look like file records, they are all skewed. However, this is all consistent with a MFT starting at sector 6291456. Re what you said about an offset from the boot record, I would expect a different offset from the MBR and from the partion boot record to the actual MFT. the MBR sits in its own reserved space in front of the first partition, which is the one we are examining. The size of this might be 2048 sectors, i dont know. hope I got all that straight. Im not that awake! Still dont know how come I have 4 rotated records.

finally got home, so perhaps here is what you were asking for. I did read the links yesterday but found them very long winded as explanations of where to find the specific programs..Im more accustomed to eyeballing the hex to figure out whats wrong with it then feeding it into a program but I shall try to investigate that too. But as I think I said I havnt indulged for years. I naturally assumed you would just be looking at it too. afraid i dont forget the rolled cluster, which seems quite curious. damocles boot sectors.zip

it is quite possible the disk was on a computer running vista first. Ive rather given up on vista and prefer to go back to xp, but that would have been a different computer. Does this interesting chequered history make a difference? I had a look at hdhacker last night. it put up onscreen a boot sector image, but i noticed that when i typed in the cluster number of the MFT, it crashed. i think the number was too big. Fraid i cant find you a file dump until later as I am elsewhere. Do I take it you have some kind of program which will analyse the boot sectors? Incidentally, i cant be absolutely certain, but offhand I dont think I ever 'just zipped' anything in my life. This is all very exciting!

And for good measure an image of the start of the MFT on the duff partition

never done this before, so lets see what happens, i have attached a copy of the boot sector of the faulty ntfs partition. This partition is assigned a drive letter by windows but any attempt to access it generates an error. Chkdsk says 'The type of the file system is NTFS. Unable to determine volume version and state. Chkdsk aborted.' The other partition has a letter and lists its files. I dont recall now whether I put something on it before the other failed or it was always blank. It was indended just for data.I dont remember whether at the time the boot partition failed I had even formatted the other. I may have done it afterwards to see if it would. Mostly I just put the whole disk aside until i had time to investigate it. Not being absolutely certain what winhex is doing, I have also attached what I think is the MBR.

I dont know how windows would react to finding a chain of 00's where it expects the MFT to start? would it simply ignore everything until it reached a 'file' identifier, or generate an immediate error? I would think there must be the correct identifier at the start of the MFT. I also dont know what the significance of the trailing 56 04 at the end of a record is. I note there is a different end signature for most of the MFt entries, but it occurs in all the odd block, which is why i think it has somehow rolled. In any event, even if the start of the last misaligned entry is recognised, the end of it is truncated and it runs into the start of the next.

ok. I have a seagate barracuda 7200.10 hard drive. This was partitioned into two NTFS partitions and some unallocated space. windows xp was installed onto one partition and was running contentedly. Then it wasnt. After due muttering and cursing I put the disk to one side and installed and formatted another with xp. However, I would like to recover some stuff from the disk. Windows xp is happy to list the drive and show correct information about the partition sizes. Seagate disk tester says the hard disk is fine. windows says the file or data is corrupted Trying to figure out what is wrong I have hoiked up a demo version of winhex. Recommendations on something useful and free to examine and edit the disk would be appreciated. Im not that good at editing disks freehand and have never worked on one formatted to ntfs. However, I have just about managed to explore the working disk on this computer and locate the MFT. Then had a look at the bad one. What I see is that the initial MFT entries are not aligned on sector borders but are 16 bytes further in. On my working disk I get MFT start at offset C0 00 00 00 with the signature 45 39 4c 30 03. (ascii 'File0') I take it these are standard values. On the duff disk I get the same data pattern at c0 00 00 10 the first 16 bytes where the MFT ought to appear are 14 00's and then 56 04 at offset c0 00 10 00 the correct pattern seems to reassert itself with a 'FILE0' signature at the start of a record where it ought to be. The spare copy of the start of the MFT seems to have exactly the same offset problem. Anyone know whats going on? I dont understand how the data gets to be misaligned displaced from sector boundaries. What does anyone reckon that if this block of 8 sectors is 'rotated' by 16 bytes so that the extra block of 00's and what appears to be a record ending signature of 56 04 is placed as the last 16 bytes instead of the first, then the partition will be fixed?