Disk not being recognised in unit or in Windows

Why is it saying "writes to Humax disk are disabled"? Is that going to prevent it actually writing the new partition table?
 
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.;)
 
Ed Ludlow said:
Why is it saying "writes to Humax disk are disabled"? Is that going to prevent it actually writing the new partition table?
Click to expand...
Because you didn't supply the '-w' option. However, it will still fail if it can't find three partitions.
 
xyz321 said:
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.;)
Click to expand...
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.
 
You could try looking at offset 8192 with a hex editor. This should correspond to the beginning of the first partition.
 
Mike0001 said:
Think of a library. Someone went in and cut every page out of every book and threw them all on the floor.
Click to expand...
af123 said:
I think you mean the file allocation table.
Click to expand...
Mike0001 said:
No, I meant the partition table.
Click to expand...
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.
 
Black Hole said:
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.
Click to expand...


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:
 
You must log in or register to reply here.
Back
Top