Hex & binary arithmetic to fix disks?

[n***@gmail.com]

I couldn't remember why I had just 'linked-over' the detached partition.

Here's the explanation:-
I've got a table of the adddress of Mr.A, B, C

A: -> 13 -xx
B: -> 22 cxxxxxxxxx
C: -> 85 dxxxxx
so I can go and visit any one of them,
but the proper way to contact C is to phone the first
person-in-the-chain, who will phone the next, until
A phones B phones C.

Only B knows the phone-number of C.
But we can't follow the chain to get B's number, since it's
been lost by A. But we can physically visit Mr.B, and physically
take C's number to A. So now A can contact C by just skipping B.

Can you improve on that?

"cxxxxxxxxx" represents partition:B,
starting with the link/phone-number to C.

It's quiet difficult to derive [the 16 bytes] b from B.
Do any readers have the details - possibly from google?
IMO this is valuable info to have, and there's no need to see
partition-tables a quantum physics.

I've repeately failed to recover 'unlinked' partitions
useing available tools: testdisk [the latest version is on the
very partition which is unlinked]; lipe, gparted....
Have you noticed how all he tools give a different story?

Can we share the effort to solve this often needed tool?
I've got a lot of logs and info to contribute.
Of course my method only works if you've kept the table of
partition start-sectors. With the 64-offset the PartnTbl's
location can be exactly found/confirmed by searching with:
dd if=/dev/X skip=<near startSector> count=<reducingSize> |hexdump -C

Windows users apparently don't need partitions.
*nix may want about 6.
Native-Oberon wants about 36.

== TIA.

[David W. Hodgins]

Post by n***@gmail.com
I've got a table of the adddress of Mr.A, B, C
A: -> 13 -xx
B: -> 22 cxxxxxxxxx
C: -> 85 dxxxxx
so I can go and visit any one of them,
but the proper way to contact C is to phone the first
person-in-the-chain, who will phone the next, until
A phones B phones C.
Only B knows the phone-number of C.
But we can't follow the chain to get B's number, since it's
been lost by A. But we can physically visit Mr.B, and physically
take C's number to A. So now A can contact C by just skipping B.

The above appears to be referring to partition chaining. This only
applies to partitions within an extended partition, on a drive using
an msdos style mbr.

The first four partitions are stored directly in the mbr partition
table. No chaining involved. In order to have more than 4 partitons,
one of those 4 must be an extended partition.

The 5th partition will have a link pointing to the 6th, which will
have a link pointing to the 7th.

If the 6th partition is deleted, the pointer in the 5th will be
changed to point to the 7th (which becomes the 6th).

If the now empty space is used to create another partition, it will
become the 7th partition, with a link set in the 6th.

The logical order of the partitions is no longer the same as the
physical order. Before the delete, the partitions were physically
in the order 5, 6, 7. After the delete/create, the partitions are
then in the order 5, 7, 6.

If you don't want the partition order to be changed, never delete
a partition within the extended partition. Just format (mkfs), and
resize/move if needed.

Regards, Dave Hodgins

[n***@gmail.com]

Post by David W. Hodgins

Post by n***@gmail.com
I've got a table of the adddress of Mr.A, B, C
A: -> 13 -xx
B: -> 22 cxxxxxxxxx
C: -> 85 dxxxxx
so I can go and visit any one of them,
but the proper way to contact C is to phone the first
person-in-the-chain, who will phone the next, until
A phones B phones C.
Only B knows the phone-number of C.
But we can't follow the chain to get B's number, since it's
been lost by A. But we can physically visit Mr.B, and physically
take C's number to A. So now A can contact C by just skipping B.

The above appears to be referring to partition chaining.

---snip---
Yes, it is assumed that readers know that.
What I couldn't understand was why I had sacrificed the one
<backup data> partition, by jumping-over-it, after spending so
much effort. The reason appears to be that it was just easy to
copy the 16-byte<link> in N to N+1, and paste it into N-1.
Which assumes that the addressing is absolute.

Post by David W. Hodgins
The 5th partition will have a link pointing to the 6th, which will
have a link pointing to the 7th.
If the 6th partition is deleted, the pointer in the 5th will be
changed to point to the 7th (which becomes the 6th).

Only if it's deleted 'under control' not skipped over, by
going under the hood.

Post by David W. Hodgins
If the now empty space is used to create another partition, it will
become the 7th partition, with a link set in the 6th.

Which means the 'deletion' consisted of <removing it from the
active-chain, and placing it on the avaiable-chain>.

Post by David W. Hodgins
The logical order of the partitions is no longer the same as the
physical order. Before the delete, the partitions were physically
in the order 5, 6, 7. After the delete/create, the partitions are
then in the order 5, 7, 6.
If you don't want the partition order to be changed, never delete
a partition within the extended partition. Just format (mkfs), and
resize/move if needed.

I can't imagine a reason to need the physical & logical ordering
to match.

Yes but that loses the info of the newly formatted partition.
For the new problem, I need to go to a 'deeper level' to restore
the link and save the partition with its contents.
Hence the partionTbl fields decoding and binary arithmetic.

Post by David W. Hodgins
Regards, Dave Hodgins

Can you do the <16 byte decoding> from the known start sector?

Post by David W. Hodgins

Post by n***@gmail.com
Can we share the effort to solve this often needed tool?

Only needed often by those who failed to take backups or do a nightly
rsync.,..
--

I want to speak with the engineyear, not the insurance salesman.

[The Natural Philosopher]

Post by n***@gmail.com
Can we share the effort to solve this often needed tool?

Only needed often by those who failed to take backups or do a nightly
rsync.,..

[Michael Black]

Post by The Natural Philosopher

Post by n***@gmail.com
Can we share the effort to solve this often needed tool?

Only needed often by those who failed to take backups or do a nightly
rsync.,..

Like that time there was an upgrade a couple of months ago for my
Microsoft Surface 2 Tablet, and something went wrong.

It's telling that while I've accidentally erased things while using Linux,
I've never had Linux destroy things in 14 years of using it.

Michael