• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
  • The forum software that supports hummy.tv has been upgraded to XenForo 2.0!

    This is a major upgrade which changes the look and feel of the forum somewhat but brings a host of improvements too. Please bear with us as we continue to tweak things and report any issues or suggestions in Site/Forum Issues.

Disk not being recognised in unit or in Windows

xyz321

Well-Known Member
#22
humaxcheck -p does recreate the MBR. It does this by looking at the beginning of the first partition and reading its header information. This provides (amongst other things) information about the start and length of the partition. Once it has these parameters it then knows where to look for similar information from the next partition etc. If it finds all three partitions it can then remake the MBR. In this case it seems that (at least) the beginning of the first partition has been overwritten.

I seem to vaguely remember someone having successfully recovered their MBR after a Windows initialisation but I can't remember what machine was or what version of Windows was used to break it.;)
 

MartinLiddle

Super Moderator
Staff member
#25
I seem to vaguely remember someone having successfully recovered their MBR after a Windows initialisation but I can't remember what machine was or what version of Windows was used to break it.;)
I definitely know of people who have successfully done this on a 9200T but I don't know what version of Windows was used to overwrite it originally.
 

Black Hole

May contain traces of nut
#28
Think of a library. Someone went in and cut every page out of every book and threw them all on the floor.
I think you mean the file allocation table.
No, I meant the partition table.
I agree with AF - that is a lousy analogy for a partition table, much better as an analogy for a FAT. The partition table only specifies what part of the disk each partition occupies (and by implication the location of each FAT) - so corrupting it is like throwing away the key to the room that contains the library index, not actually disordering the library.
 

Mike0001

Well-Known Member
#29
I agree with AF - that is a lousy analogy for a partition table, much better as an analogy for a FAT. The partition table only specifies what part of the disk each partition occupies (and by implication the location of each FAT) - so corrupting it is like throwing away the key to the room that contains the library index, not actually disordering the library.

The library is already disordered. Without the partition table all you have is a jumble of sectors on a HDD.

I purposely avoided mentioning the FAT because partitions don't necessarily have a FAT. NTFS's MFT springs to mind. So, your "location of each FAT" makes no sense whatsoever unless this particular machine uses FATs. In particular, the partition table does not imply the location of any FATs on a drive that might have no FAT, eg, an NTFS drive.

Anyway, it is irrelevant because Ed knew about this already. I assume you are arguing for the sake of it, as usual?:disagree: