Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

still no partition on Seagate after successful unbrick

- - - - -

  • Please log in to reply
62 replies to this topic

#51
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • Joined 15-June 10
  • OS:XP Pro x86
  • Country: Country Flag
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 :wacko:
thanks a lot


How to remove advertisement from MSFN

#52
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,567 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
No, there must be something being lost in translation (either "human" translation or "batch/program" one). :unsure:

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? :w00t:
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

#53
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • Joined 15-June 10
  • OS:XP Pro x86
  • Country: Country Flag
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 :unsure:

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 Files

  • Attached File  drdd.JPG   66.84KB   5 downloads


#54
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,567 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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 :unsure:

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. :unsure:

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

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):

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


Edited by jaclaz, 10 November 2012 - 09:01 AM.


#55
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • Joined 15-June 10
  • OS:XP Pro x86
  • Country: Country Flag
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 !!! :rolleyes:
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 ?
:blink:
my G: partition is a good one, it's a single partionned disk in NTFS.

thanks

#56
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,567 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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 !!! :rolleyes:
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 ?
:blink:
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 :blushing: , what (the HECK :unsure: ) is your G:\ drive? :w00t:

(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 :ph34r: )

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 :ph34r: , 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

#57
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • Joined 15-June 10
  • OS:XP Pro x86
  • Country: Country Flag
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

#58
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,567 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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 :unsure: :
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

#59
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • Joined 15-June 10
  • OS:XP Pro x86
  • Country: Country Flag
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 !!

:realmad:

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

#60
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,567 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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 :unsure:

JFYI, the 2048 offset is the "normal" offset for first Primary partition on a disk partitioned on either Vista :ph34r: 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

#61
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • Joined 15-June 10
  • OS:XP Pro x86
  • Country: Country Flag
hi Jaclaz,

so, I'm extracted all the extents from the faulty hard drive (with errors of course).
I'm trying to inject them in a new file using:
fsz c:\newfile.pds 548864

then:
dsfi c:\newfile.pds 0 0 extent1.dd
then:
dsi c:\newfile.pds 8192 0 extent2.dd
and I receive the error:
c:\newfile.pds: no data available

any idea what's wrong ? :}
thanks again !

#62
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,567 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
There is seemingly nothing wrong (there is a typo with dsi instead of dsfi, but this is most probably just in the post).

You shouldn't however work on root.
Make a directory, say C:\recwork
Copy to it fsz, dsfo, dsfi and the files extendn.dd.

Open a command prompt and run in it again those commands , then run:
DIR C:\recwork\*.dd>C:\recwork\dir.txt
DIR C:\recwork\*.pds>>C:\recwork\dir.txt
post the dir.txt contents, maybe there is an issue with size of files? :unsure:

jaclaz

#63
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • Joined 15-June 10
  • OS:XP Pro x86
  • Country: Country Flag
sorry, after making the command you asked me, I've seen that extent2 and 3 were at "0" size ! :whistle:

unfortunatly, I've merged all the extents and I have as a result, a beautiful file, full of "0xFF" values only !!
I've also opened all the extracted extents, it's the same, 0xFF everywhere .... :(
so, I guess I can leave this file alone , and I will try on another one

thanks again




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users