still no partition on Seagate after successful unbrick

[jaclaz]

with myfragmenter, I have more results:

MyFragmenter.exe -i f:\montage\2011-tmp.pds

MyFragmenter v1.2, 2008 J.C. Kessels

Commandline argument '-i' accepted.

Processing: f:\montage\2011-tmp.pds

Fragment list:

Extent 1: Lcn=495625, Vcn=0, NextVcn=2

Extent 2: Lcn=28135076, Vcn=2, NextVcn=4

Extent 3: Lcn=48751063, Vcn=4, NextVcn=8

Extent 4: Lcn=48797290, Vcn=8, NextVcn=16

Extent 5: Lcn=50038742, Vcn=16, NextVcn=32

Extent 6: Lcn=26068714, Vcn=32, NextVcn=48

Extent 7: Lcn=94098378, Vcn=48, NextVcn=65

Extent 8: Lcn=74619826, Vcn=65, NextVcn=80

Extent 9: Lcn=95440487, Vcn=80, NextVcn=99

Extent 10: Lcn=106615323, Vcn=99, NextVcn=112

Extent 11: Lcn=95441871, Vcn=112, NextVcn=131

Extent 12: Lcn=48579698, Vcn=131, NextVcn=134

134 clusters, 12 fragments.

Finished, 1 files processed.

Good.

what do you suggest for next step ?

thanks a lot

Try using the attached batch.

The output of myfragmenter is expressed in Logical Cluster Number (relative to the Volume) and Virtual Cluster numbers (relative to the file).

The batch converts (or attempts to ) those in "plain" "absolute" (i.e. relative to the disk) LBA addreses and Sectors lengths of the chunks or extents.

The settings:

Set InitialLBA=63

Set clusterSize=8

are already set in the batch for the disk values you have.

jaclaz

myfragi.zip

[onlit4regs]

here we go with your magic batch !

Ext: Lcn: LBAstart: Sects: File:

1 495625 3965063 16 f:\montage\2011-tmp.pds

2 28135076 225080671 16 f:\montage\2011-tmp.pds

3 48751063 390008567 32 f:\montage\2011-tmp.pds

4 48797290 390378383 64 f:\montage\2011-tmp.pds

5 50038742 400309999 128 f:\montage\2011-tmp.pds

6 26068714 208549775 128 f:\montage\2011-tmp.pds

7 94098378 752787087 136 f:\montage\2011-tmp.pds

8 74619826 596958671 120 f:\montage\2011-tmp.pds

9 95440487 763523959 152 f:\montage\2011-tmp.pds

10 106615323 852922647 104 f:\montage\2011-tmp.pds

11 95441871 763535031 152 f:\montage\2011-tmp.pds

12 48579698 388637647 24 f:\montage\2011-tmp.pds

[jaclaz]

here we go with your magic batch !

Ext: Lcn: LBAstart: Sects: File:

1 495625 3965063 16 f:\montage\2011-tmp.pds

2 28135076 225080671 16 f:\montage\2011-tmp.pds

3 48751063 390008567 32 f:\montage\2011-tmp.pds

4 48797290 390378383 64 f:\montage\2011-tmp.pds

5 50038742 400309999 128 f:\montage\2011-tmp.pds

6 26068714 208549775 128 f:\montage\2011-tmp.pds

7 94098378 752787087 136 f:\montage\2011-tmp.pds

8 74619826 596958671 120 f:\montage\2011-tmp.pds

9 95440487 763523959 152 f:\montage\2011-tmp.pds

10 106615323 852922647 104 f:\montage\2011-tmp.pds

11 95441871 763535031 152 f:\montage\2011-tmp.pds

12 48579698 388637647 24 f:\montage\2011-tmp.pds

Good, now you should be able to put (copy and paste or, better import) the contents of the .log into a spreadsheet.

In theory you have a "good" or almost good 134 Gb image, so anything (roughly, you will have to make the math exactly) before:

134 GB=~134*1024*1024*1024=143881404416/512=LBA 2766950084

should be already on your image, so in the spreadsheet you order by LBA address and get the chunks that are missing.

Now there is the usual doubt about which strategy to use to get the missing data.

Basically there are two theories - no way to know which one may give you "better" results, depending on the actual issue one or the oher may work better, or both could work the same, or both could fail:

1. theory of "little by little" <- you just try to get the chunk that you need
   
2. theory of "greater area" <- you try to get an area of the orignal disk larger than the chunk(s) you need, and then you re-parse this to get the exact chunks
   

Theory #1 is based on the hypothesis that the head going to a given place is more exact" than "passing by", theory #2 is based ont the opposite hypothesys.

Of course on a disk that has no issues both would work perfectly, but you never know, additionally datarescuedd has also an option to get sectors in "reverse reading", which sometimes helps.

The BAD news are that seemingly, and though fragmented, that particular file seems like being entirely within he first 134 Gb .

Which could mean that your image already contains some corruprted sector

Try getting all single chunks from the original disk with datarescueDD.

Once you have extracted (hopefully) all 12 "chunks", you can re-assemble them by using COPY +, but it is usually more convenient using some od the tools in DSFOK toolkit:

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

If you sum the sizes of the chunks in the spreadsheet you get 1072 sectors, i.e. 1072*512=548864 which should also be the size of the file that you see in Explorer or in DIR...

So you do:

fsz C:\mytemp.dat 548864

This will create an empty file of that size in bytes.

Then you use:

dsfi C:\mytemp.dat <offset> 0 <filechunk.dd> 

which means copy to C:\mytemp.dat, starting from offset <offset> for all it's length (0) the <filechunk.dd> where offset is the offset in BYTEs of the filechunk and the <fileschunk> is the name of the file extracted with datarescuedd, the first chunk with your data should be image[2030112256-2030120448].dd (where obviously 2030112256 is made by the LBA offset*512=3965063*512=2030112256 and 2030120448 is the offset+the length, i.e. 3965063*512+16*512=2030120448)

The use of a spreadsheet is advised as it will produce the exact command lines faster and without the risk of typing errors.

jaclaz

[onlit4regs]

fsz C:\mytemp.dat 548864

This will create an empty file of that size in bytes.

Then you use:

dsfi C:\mytemp.dat <offset> 0 <filechunk.dd> 

which means copy to C:\mytemp.dat, starting from offset <offset> for all it's length (0) the <filechunk.dd> where offset is the offset in BYTEs of the filechunk and the <fileschunk> is the name of the file extracted with datarescuedd, the first chunk with your data should be image[2030112256-2030120448].dd (where obviously 2030112256 is made by the LBA offset*512=3965063*512=2030112256 and 2030120448 is the offset+the length, i.e. 3965063*512+16*512=2030120448)

The use of a spreadsheet is advised as it will produce the exact command lines faster and without the risk of typing errors.

jaclaz

ok, just to be sure I understand the offset in the dsfi command, for the second chunk, I'll have to use:

dsfi c:\mytemp.dat 8192 0 filechunk2.dd

(16*512 = 8192)

is that right ?

thank a lot

[jaclaz]

ok, just to be sure I understand the offset in the dsfi command, for the second chunk, I'll have to use:

dsfi c:\mytemp.dat 8192 0 filechunk2.dd

(16*512 = 8192)

is that right ?

thank a lot

Yep

The spreadsheet could look something *like*:

By LBA	Ext:	 Lcn:	 	 LBAstart:	 Sects:	File:	 	 	 Limit:	 	 ROffset:  ROffsetB:
#1	1	 495.625 	 3.965.063 	16	f:\montage\2011-tmp.pds	 2.766.950.084 	 -   	 -   
#3	2	 28.135.076 	 225.080.671 	16	f:\montage\2011-tmp.pds	 2.766.950.084 	 16 	 8.192 
#5	3	 48.751.063 	 390.008.567 	32	f:\montage\2011-tmp.pds	 2.766.950.084 	 32 	 16.384 
#6	4	 48.797.290 	 390.378.383 	64	f:\montage\2011-tmp.pds	 2.766.950.084 	 64 	 32.768 
#7	5	 50.038.742 	 400.309.999 	128	f:\montage\2011-tmp.pds	 2.766.950.084 	 128 	 65.536 
#2	6	 26.068.714 	 208.549.775 	128	f:\montage\2011-tmp.pds	 2.766.950.084 	 256 	 131.072 
#9	7	 94.098.378 	 752.787.087 	136	f:\montage\2011-tmp.pds	 2.766.950.084 	 384 	 196.608 
#8	8	 74.619.826 	 596.958.671 	120	f:\montage\2011-tmp.pds	 2.766.950.084 	 520 	 266.240 
#10	9	 95.440.487 	 763.523.959 	152	f:\montage\2011-tmp.pds	 2.766.950.084 	 640 	 327.680 
#12	10	 106.615.323 	 852.922.647 	104	f:\montage\2011-tmp.pds	 2.766.950.084 	 792 	 405.504 
#11	11	 95.441.871 	 763.535.031 	152	f:\montage\2011-tmp.pds	 2.766.950.084 	 896 	 458.752 
#4	12	 48.579.698 	 388.637.647 	24	f:\montage\2011-tmp.pds	 2.766.950.084 	 1.048 	 536.576

where Roffset= Sects+Previous ROffset and ROffsetB=ROffset*512

The "0" means "copy the whole size" of the following "chunk", you could use instead the exact size of the chunk in bytes, but it only makes more complex the command, i.e. it could be:

dsfi c:\mytemp.dat 8192 0 filechunk2.dd

dsfi c:\mytemp.dat 8192 8192 filechunk2.dd

(by coincidence the second chunk is actually 16 sectors i.e. 8192 bytes in size)

jaclaz

[onlit4regs]

something is going wrong on what I've done

I tried on a file that was readable on my image:

myfragi returns this:

1 769865 6158983 624 f:\photos\PHOTOS~1\35ANSM~1.JPG

in drdd, you wrote to x512 for the LBA start but values are in sector, so I have left the values from myfragi:

start: 6158983 (sectors) - I can not write 6158983*512 = 3153399296, it doesn't fit in the software (only nine digit not ten)

size: 624 (sectors)

then :

fsz c:\test.jpg 319488

and finally:

dsfi c:\test.jpg 0 0 c:\image[3153399296-3153718784].dd

and the image is unreadable

(it was OK in windows explorer on my500gb.img)

I've misunderstand something in the values for drdd

thanks a lot

[jaclaz]

No, there must be something being lost in translation (either "human" translation or "batch/program" one).

It seems to me like you did everything "right".

Myfragmenter provides the LCN (that is Logical cluster number).

On your disk a cluster is made by 8 sectors and there is an initial offset of 63 sectors to the volume (or start of the Logical Cluster Number).

The myfragi batch takes the LCN and converts it in Absolute LBA, i.e. it converts 769865*8+63=6158983

As well it takes the difference beween Vcn's and multiplies it by 8, i.e. if you run directly myfragmenter -i you should get for that file Vcn=0, NextVcn=78 and the myfragi does (78-0)*8=624

And the file should be 624*512=319488

In drdd you use LBA so you should have start 6158983 and length 624.

Since this file is already in one chunk, the result should be already the file.

But these seem right:

fsz c:\test.jpg 319488

and finally:

dsfi c:\test.jpg 0 0 c:\image[3153399296-3153718784].dd

The only issue is that since the myfragmenter uses clusters as "unit", the resulting file might be larger (up to the cluster border) than the original, this shouldn't be a problem for images like JPEG, but it may be an issue with other data formats, in which case you use again fsz to "cut" the file to the exact bytes length you have in Explorer or in a DIR command.

Could it be an issue with the initial offset?

Maybe the my500Gb.img, being mounted in IMDISK (which ignores hidden sectors/first track) shifts the addresses? (but it doesn't "sound" right)

Try doing a test with a file on your "main", working drive and or, try accessing the same file with DMDE, the LBA and LCN should be the same as the ones provided by myfragi.

If they are, the only sensible explanation is that the reading of those particular sectors from the "original" disk drive are now failing (while they worked when you made the 134 Gb image....

jaclaz

[onlit4regs]

on a working drive and a working file:

myfragi.cmd g:\test.jpg

1 52254759 418038135 3104 g:\test.jpg

in drdd, I've extracted the sectors, but file is not a valid image. (I didn't use fsz nor dsfi this time)

I've enclosed the drdd capture, just to be sure I am not wrong with values

on DMDE, when opening the image my500gb.img, and selecting the previous image test file, I have the same LBA: 6158983, vol.sec:6158920, clus:769865

when opening with DMDE the mounted logical drive of IMD, the LBA is 6158920, vol.sec:6158920, clus:769865

(on the Open NTFS Volume message box, start offset is set to 0)

[jaclaz]

on a working drive and a working file:

myfragi.cmd g:\test.jpg

1 52254759 418038135 3104 g:\test.jpg

in drdd, I've extracted the sectors, but file is not a valid image. (I didn't use fsz nor dsfi this time)

I've enclosed the drdd capture, just to be sure I am not wrong with values

on DMDE, when opening the image my500gb.img, and selecting the previous image test file, I have the same LBA: 6158983, vol.sec:6158920, clus:769865

when opening with DMDE the mounted logical drive of IMD, the LBA is 6158920, vol.sec:6158920, clus:769865

(on the Open NTFS Volume message box, start offset is set to 0)

Yes, the behaviour of dmde is "normal", the Physicaldrive (and obviously the my500gb image) start at absolute sector LBA 0, th actual Volume (drive letter) starts at absolute LBA 63, which becomes Relative LBA 0, hence the LBA: 6158983, vol.sec:6158920 63 sectors difference, when you open the Volume, it's initial offset is 0 (as you are not accessing the physicaldrive, but rather a virtual disk through IMDISK, that simply "fakes" that the Volume is a Superfloppy with no sectors before).

In theory in datarescuedd you should select NOT the Volume (drive letter) but rather the disk (something like "drive 2"), but it should NOT make any difference.

Is it not that the resulting image file is locked by the still open datarescuedd?

I'll check if I can give you an alternate tool to try instead of datarescuedd.....

jaclaz

EDIT:

Try with pldd, here:

http://home.comcast.net/~plavarre/plscsi/tools/pldd/

The syntax you should use is, given:

myfragi.cmd g:\test.jpg
1 52254759 418038135 3104 g:\test.jpg

the following (make sure you get the right \\PhysicalDrive number n):

pldd if=\\.\\Physicaldriven of=C:\test.dat bs=512 skip=418038135 count=3104

Edited November 10, 2012 by jaclaz

[onlit4regs]

I've closed drdd before viewing the image.

I've tried with selection also the physical drive in drdd

same result

with pldd, I've done a few test, it's the same with my image file on G:\

BUT

when I try the same image on my C: drive, it works !!!

so, this may be also the same problem with the image mounted drive letter ?

any hint on why it works on C: and not further ?

my G: partition is a good one, it's a single partionned disk in NTFS.

thanks

[jaclaz]

I've closed drdd before viewing the image.

I've tried with selection also the physical drive in drdd

same result

with pldd, I've done a few test, it's the same with my image file on G:\

BUT

when I try the same image on my C: drive, it works !!!

so, this may be also the same problem with the image mounted drive letter ?

any hint on why it works on C: and not further ?

my G: partition is a good one, it's a single partionned disk in NTFS.

thanks

Wait a minute, now that I think of it , what (the HECK ) is your G:\ drive?

(if it is not the first primary volume on a hard disk partitioned with the "traditional" CHS aligned scheme it's offset will NOT be 63 )

The idea is that what myfragmenter gets is the Logical Cluster number, that is ALWAYS relative to the begin of the volume.

The myfragi batch translates it to ABSOLUTE LBA (starting from the start of the DISK) by multiplying the cluster number by cluster size and ADDing to it the offset (63 in the case of that disk/volume).

If you access the original disk, you need the absolute LBA, if you access an image mounted with IMDISK (that ignores the 63 sectors before) you should subtract from the result of myfragi 63 sectors (or better change the data in the batch, see below) if you are using any disk where the volume does not start at 63 you need to change the offset in the batch (or manually add/subtract the difference), these are variables in myfragi.cmd:

Set InitialLBA=63

Set clusterSize=8

A "normal" NTFS formatted volume will have clusters sized 8 sectors (but not necessarily) while the initial offset (where the Volume starts on the disk) is 63 ONLY if it is first primary partition and the disk is formatted "normally", i.e. before Vista , if that disk has been partitioned bu another OS or through a third party utility, the Volume may start at *any* LBA offset.

Are you sure you are using the "right" PhysicalDrive? I will reiterate how datarescuedd numbers them starting from 1, whilst Disk Manager and any other utility using the \\.\\Physicaldriven object to access a disk numbers them from 0.

jaclaz

[onlit4regs]

yes I'm sure I've used the right physical drive number, as stated in windows disk manager

this G: drive has only a primary partition. I'm not sure that it was really created under windows xp, I can't remember

how to check the offset and cluster size on this partition ?

anyway, that was just a hint for understanding why the drdd didn't work on the mounted image of my faulty drive ? but it seems it's not associated ....?

thanks a lot

[jaclaz]

how to check the offset and cluster size on this partition ?

anyway, that was just a hint for understanding why the drdd didn't work on the mounted image of my faulty drive ? but it seems it's not associated ....?

Open the physicaldrive in DMDE (since you have it handy), you know like:

Yes, the behaviour of dmde is "normal", the Physicaldrive (and obviously the my500gb image) start at absolute sector LBA 0, th actual Volume (drive letter) starts at absolute LBA 63, which becomes Relative LBA 0, hence the LBA: 6158983, vol.sec:6158920 63 sectors difference, when you open the Volume, it's initial offset is 0 (as you are not accessing the physicaldrive, but rather a virtual disk through IMDISK, that simply "fakes" that the Volume is a Superfloppy with no sectors before).

There is this point that you seem to have not grasped completely :

LBA of a sector (on an opened Physicaldrive or image of it) is ABSOLUTE

vol sec (on the same sector) is RELATIVE to volume.

Hence (in the given example that you provided) 6158983-6158920=63 this is the offset to the beginning of the volume.

BUT if you mount the physicaldrive image with IMDISK, because of the specific way IMDISK works, the offset to the volume becomes 0 and thus Absolute LBA and Relative LBA are the same.

I hope now this matter is more clear.

About further attempts to recover from the failed drive, there are two "levels" of issues:

1. first is to make sure that you are getting the "right" sectors, which you can verify by doing tests with some files that you also already have in the 134 or 500 Gb image
   
2. second is to hope (you cannot do much more than that) that those sectors are readable and adre not corrupted.
   

Right now it is not yet clear if you are still in the first level or if you are (unfortunately) in the second and the sectors for that particular file are either corrupted or unreadable.

jaclaz

[onlit4regs]

hi jaclaz

well, I've done the test again, and I've finally succeeded in getting my test file on G: restored. (the offset on my drive G: was 2048 !)

I've also succesfully restored an "already working" file on the image file, I have now the right sectors !

so, I've decided to try on a faulty file now.

unfortunatly, when trying to extract the 1st extent of 16 sectors only, drdd said:

read error at ....: incorrect function

read error at ....: semaphore delay has expired ....

and several times !!

do you think this extent is usuable ? certainly not

is this really lost ? is this because of the unbrick ? a problem with the unbrick ?

thanks

[jaclaz]

so, I've decided to try on a faulty file now.

unfortunatly, when trying to extract the 1st extent of 16 sectors only, drdd said:

read error at ....: incorrect function

read error at ....: semaphore delay has expired ....

and several times !!

Yep, that is one of the possible issues.

You can try three alternate strategies:

1. try imaging the same sectors "backwards"
   
2. try imaging a larger chunk of sectors (and then extract from the larger chunk the relevant sectors)
   
3. try imaging a larger chunk of sectors "backwards" (and then extract from the larger chunk the relevant sectors)
   

It is UNlikely that the issue is due to the UNbricking, unless maybe if you cleared the G-List or whatever is cleared with i4,1,22 command, and that extent is/was on remapped sectors (still in the idea that it belongs to the part of the disk that you imaged in the 134 Gb), it is much more likely that your disk "bricked" because of some issue, and this issue is the reason.

It is difficult to say if once diagnosed properly with suitable tools those sectors can be made accessible again

JFYI, the 2048 offset is the "normal" offset for first Primary partition on a disk partitioned on either Vista or 7 with "default settings".

Data recovery, in general, and expecially at a DIY with simple tools level, is more than anything else a sometimes you win, sometimes you lose kind of game .

A professional recovery of that drive (if possible) can be anything in a range from US$ 500 up to a few thousands, it's up to you to determine the monetary value of those files you are missing.

I am not familiar (specifically) with .pds files, maybe even if you miss the initial 16 sectors of it, it can be rebuilt/recovered or however important info retrieved from the rest of the file (or the program making those makes a temporary file from which you can gather the missing sectors)....

jaclaz