disks differ after cloning with dd
Hello.
Few days ago, I tried to clone a damaged[1] disk to another one, of the
same size, with dd.
I had to interrupt the copy after more than 24 hours, because it was
obviously too long[2].
Now, I am trying to look anew how to do the copy, and looking at the
disks with gparted, I have those messages when it inspects the target of
the copy:
======
The backup GPT table is corrupt, but the primary appears OK, so that
will be used.
Could not detect file system.
======
What is strange, is that it seems to detect all file systems: fat32 for
a small first partition (which is bootable... I could take a look at it,
it sounds promising. It is labeled "EFI", I wonder what it is...), hfs+
for the bigger one (~465GB), and some non allocated space. Lot of it:
128GB.
Looking at the source disk, I have the same results, but without the
error message and with "unknown" as 2nd file system.
I made the error of not writing somewhere informations of the damaged
disk before trying to clone it.
The questions I have:
How could an interrupted dd "fix" a file system?
I do not remember having seen so much unused space on first disk. Could
dd have written stuff there, when I only asked it to read there?
How could I fix that endless copy, or at least how could I know why or
what dd is copying endlessly?
1: at least one of it's partitions is: the problem being that, after
plugging it into a windows system, content suddenly disappeared. It was
previously (only?) used on a mac system. Those disks are not mine so I
do not have a lot of knowledge about how they were used.
2: the 2 disks are USB drives of 500GB. I was very reluctant to
interrupt the copy, but had no other choice at that point, since it was
obvious that it entered in some sort of infinite loop... no idea why,
since dd does not seems to give any details on what it is doing ( no
verbose mode AFAIK ).
Reply to: