Disk not being recognised in unit or in Windows

[Ed Ludlow]

Why is it saying "writes to Humax disk are disabled"? Is that going to prevent it actually writing the new partition table?

 

[xyz321]

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.

 

[xyz321]

Why is it saying "writes to Humax disk are disabled"? Is that going to prevent it actually writing the new partition table?

Because you didn't supply the '-w' option. However, it will still fail if it can't find three partitions.

 

[Ed Ludlow]

Ah that makes sense - with the -w option I get "partition table not modified, not enough partitions".

 

[MartinLiddle]

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.

 

[Ed Ludlow]

I'll do some digging on this. Do also have access to Unix and OSX, so hopefully I can find a solution...

 

[xyz321]

You could try looking at offset 8192 with a hex editor. This should correspond to the beginning of the first partition.

 

[Black Hole]

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.

 

[Deleted member 473]

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?

 

[MartinLiddle]

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 paerticular machine uses FATs.

It does have a FAT see http://humaxdisk.wikispaces.com/9200T+FS