[onlit4regs]

sorry, but how to use your batch ?
gfe.cmd driverletter: ??

thanks

[jaclaz]

onlit4regs, on 08 November 2012 - 07:40 AM, said:

sorry, but how to use your batch ?
gfe.cmd driverletter: ??

thanks

No, you need to provide the full path to the target file.
If you want to know the extents of file (say) F:\my_path\my_file.ext, you would normally run:

GetFileExtents.exe F:\my_path\my_file.ext

hence:

gfe.cmd F:\my_path\my_file.ext

or

gfedec.cmd F:\my_path\my_file.ext

jaclaz

[onlit4regs]

GetFileExtents always returns me this error:
initFileTranslation: invalid descriptor

(even when I try on the file that was recoverable)

[jaclaz]

onlit4regs, on 08 November 2012 - 08:15 AM, said:

GetFileExtents always returns me this error:
initFileTranslation: invalid descriptor

(even when I try on the file that was recoverable)

Hmmm.
Try it on a file on another volume (a "good" one, with a working filesystem).
For very small files it won't work as they are stored directly in the $MFT, but it should otherwise work (I don't think that there are issues with the "sparse" nature of the underlying file, as it is mounted in IMDISK, you could try using a different mounting tool/driver, but it shouldn't actually matter).

Try another tool.

Get myfragmenter:
http://www.mydefrag....Fragmenter.html
(part of mydefrag):
http://www.mydefrag....AndInstall.html
make SURE to use it with the -i switch, i.e.

myfragmenter.exe -i F:\my_path\my_file.ext

What happens?

Also please, when posting the result of a command, post also the EXACT way you invoked it (command line), you did not specify how you invoked GetFileExtents, it could be that you invoked it wrongly (in the sense of having given it a non existing path or whatever)...

jaclaz

[onlit4regs]

so, the command I used was:
getfileextents F:\myfile.txt
and always get the same error: initFileTranslation: invalid descriptor

on a "good" partition, it worked ! no problem. It's only with the mounted image that cause problems.

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.


what do you suggest for next step ?
thanks a lot

[jaclaz]

onlit4regs, on 08 November 2012 - 02:17 PM, said:

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.

onlit4regs, on 08 November 2012 - 02:17 PM, said:

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:

Quote

Set InitialLBA=63
Set clusterSize=8

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


jaclaz

Attached File(s)

•  myfragi.zip (544bytes)
  Number of downloads: 2

[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]

onlit4regs, on 08 November 2012 - 02:40 PM, said:

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:

• theory of "little by little" <- you just try to get the chunk that you need
  
• 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.ozema...eezip/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:

Quote

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]

jaclaz, on 09 November 2012 - 03:18 AM, said:

Quote

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]

onlit4regs, on 09 November 2012 - 05:56 AM, said:

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:

Quote

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

Quote

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:

Quote

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)

Attached File(s)

•  drdd.JPG (66.84K)
  Number of downloads: 4

[jaclaz]

onlit4regs, on 10 November 2012 - 07:33 AM, said:

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....csi/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):

Quote

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

This post has been edited by jaclaz: 10 November 2012 - 09:01 AM

[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]

onlit4regs, on 10 November 2012 - 12:17 PM, said:

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:

Quote

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]

onlit4regs, on 10 November 2012 - 04:33 PM, said:

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:

jaclaz, on 10 November 2012 - 08:22 AM, said:

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:

• 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
  
• 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]

onlit4regs, on 11 November 2012 - 03:27 PM, said:

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:

• try imaging the same sectors "backwards"
  
• try imaging a larger chunk of sectors (and then extract from the larger chunk the relevant sectors)
  
• 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