lost partition and filesystem problem with Adata SH14 disk

[nthnl]

Hello Jacklaz,

Well no, TESTDISK only showed 2 files on the disk prior to the repair and they were in the $RECYCLEBIN folder.

Yes I understand that Windows automounts the disk, but unfortunately when I was making the copy of the drive I didn't think about that and thus just made a clone of the drive.

I am ok with providing you the first 128 clusters but first I will wait for TESTDISK to complete the search and see if it will fix anything. If not then I will make an image of the original hard drive and use it to send you the clusters required.

Kind Regards,
Mihail Velikov

System Administrator

[nthnl]

Hello Jacklaz,

Sorry for the delay in my reply but I had some high priority tasks that I needed to attend to.

I have now made two copies of the original broken disk. I used the same command as before (ddrescue -r=3 -n -S -v ..) but this time I wrote the image to a file instead of imaging the whole healthy drive. I also made a copy of the image created so we can make changes and still have a original copy. I also have the ddrescue.log from the creation of the image and I will attach it to this post. As of your last request I also extracted the 9000 sectors and the resulting file is 2.2 Mb in size so I have uploaded it to a file sharing service:

http://dox.bg/files/dw?a=cc18af51f9

Please let me know if there is anything else that I can provide.

Thank you in advance.

Kind Regards,

Mihail Velikov

System Administrator

ddrescue.log.tar.gz

Edited November 28, 2013 by nthnl

[jaclaz]

Good.

I got the files and will try and see if I can get out of them some better "fake" sector 95.

In the meantime, you could see what happens running again ddrescue (with the log file, using the same destination file, see the docs):

http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Introduction

maybe using in addition the "reverse" switch and without the "n" one.

The log you posted has seemingly some "issues", there are quite a few "holes" or "gaps" in it.

By retrying with different parameters it may help in "bettering" the image, recovering some more sectors.

I am also perplexed about the "type" of the image (and of the copy of the image) you made.

I mean the effect of the "S" parameter is to have a sort of "sparse" file:

`-S'

`--sparse'

Use sparse writes for outfile. (The blocks of zeros are not actually allocated on disc). May save a lot of disc space in some cases. Not all systems support this.

Only regular files can be sparse.

and this -generally speaking - while saving the space occupied by the image, makes it "non-copy", i.e. the copy will be expanded.

How big (in bytes) is the "clean_disk_image.bin"? (filesize and size on disk)

And is the copy you made of it the SAME size?

jaclaz

[nthnl]

Hello Jacklaz,

I will use the ddrescue command again tonight and will see if there will be any change.

Regarding the size of the files, when I do ls -ltrh shows as:

clean_disk_image.bin - 931.5G

clean_disk_image.bin_orig - 931.5G

But when I do "du -h" it reports:

562Gb

And it seems to be correct because when only the single image was residing on the disk it showed 281Gb. The actual copy of the image was done by "cp". I believe the -S option works very much like "Thin provisioning".

Regarding the ddrescue.log - I have not tampered with it by any means. It is what the tool generated. When the new attempt completes I will upload the new log.

Kind Regards,

Mihail Velikov

System Administrator

[jaclaz]

Then, most probably cp works "correctly" with sparse files, this is good.

The big issue (just verified with the sectors you sent) is that the actual part I was looking for, the "Root directory" is failed/blank.

The Root starts on sector 63+32+238409+238409=476913

The bunch of sectors you sent are blank from 476913 to 476977, where a .pdf file seemingly begins.

This is confirmed by the ddrescue log:

0x0E8DE000 0x00000200 -

0x0E8DE200 0x00001C00 /

0x0E8DFE00 0x00000200 -

0x0E8E0000 0x00ECE000 +

0x0E8DE000=244178944->244178944/512=476912 <- here 512 bytes (1 sector is missing, but most likely it was empty being the "tail" of the 2nd FAT)

0x0E8DE200=244179456->244179456/512=476913 <- here there are errors extending for 7168 bytes, and these are VITAL

0x0E8DFE00=244186624->244186624/512=476927 <- here 512 bytes (1 sector is missing, but most likely it was empty being the "tail" of the Root Dir)

0x0E8E0000=244187136->244187136/512=476928 roughly 15 mb (0x00ECE000=15523840) from here are "good" :thumbsup:

As said there are more "holes" in the log, of course besides the above, the other one that would be very, very useful is this one:

0x0000BE00 0x00000200 -

Which corresponds to sector 95

The second copy of it should be on sector 238504*512=0x7475000, which is also a "hole":

0x02350000 0x05125000 +

0x07475000 0x00000200 -

0x07475200 0x0000AC00 /

The other "holes" (which would anyway be better if removed) hopefully belong to single files or to sectors that would have been anyway empty.

jaclaz