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

#26
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag
The only explanation that I can find is that *somehow* your initial attempt (post #1) with TESTDISK produced a "wrong" MBR and/or PBR.
The standard NT NTFS drivers finds *something* wrong and decides that the volume needs to be formatted.
Dmde more or less "ignores" them, analyzes the filesystem, finds the "real" $MFT and thus lists all your files "as they were". (then some may be there and some may be in the missing part and thus unavailable).
TESTDISK finds the (wrong) values it initially wrote and reads an "empy" $MFT.

Dmde is not very "easy", let's see if I can guide you into checking the data. :unsure:
Once you have loaded the $MFT (open Dmde, choose the image, search for NTFS), you should have on the left pane [All Found], if you expand it clicking on the + sign, it should read the $MFT and show everything that has been found.
Besides each file or directoryyou should have again a + sign.
Double click a directory (where you know one suitable file should be), the contents of the directory should appear on the right top pane.
Choose a (small) file of which you know the beginning of the contents (like a text file or a small program or a zip file), ideally use for the test something that belongs to the original XP install (and that thus it is likely to be in the first 134 Gb).
In the lower pane you should see the hex dump of first sector of the file (if it is there, if it is not, try with another file that you can "recognize the beginning" and that "is there") and, in the first line something *like*:

LBA:89021727 vol.sec:89021664 clus:11127708 sec:0

The LBA value is the absolute address of that sector, the vol.sec is the relative address within the volume.

Do post these values.

How much is LBA-vol.sec?
i.e.: 89021727-89021664=63 in the above example.
This would confirm that he volume starts at offset 63.

How much is vol.sec/clus?
i.e. 89021664/11127708=8
This would confirm that cluster size is 8 sectors.

Then, do something "crazy" :w00t: make a new backup of both the MBR and of the PBR (better have another copy), then open the image in tiny hexer and:
  • access the MBR sector and fill it with 00's
  • access the PBR sector and fill it with 00's

Run again Dmde on the image with the 00ed MBR and PBR and see if the results on the same file are the same as before.


jaclaz


How to remove advertisement from MSFN

#27
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
hi Jaclaz,
here are the values:
LBA : 6292581
vol.sec: 6292518
clus: 786564

so, that's offset 63 as you supposed

about the last operation you asked, I have made new backup of First boot sector of logical drive and first sector of physical drive with HDHACKER (so it saved 2 files) , and then filled them with 0, and then what to do with those 2 files ?
thanks a lot

#28
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

hi Jaclaz,
here are the values:
LBA : 6292581
vol.sec: 6292518
clus: 786564

so, that's offset 63 as you supposed

Yep, the begin offset is 63 allright but those data do not make much sense.
They are not the actual data related to a file, those correspond to entry #531 in the $MFT, possibly the $MFT entry for that file, according to the data till now gathered.
In the "upper right" pane right click on the file name, you will have a set of choices, right now you seem like having chosen "Open MFT file (hex Editor)", while you want to choose the bolded "Open (Hex Editor)".
Can you see in the lower right pane the beginning of the file?
If yes, you will also see the LBA, vol.sec, Cluster and sec. of the actual file.
Is this file recoverable?

about the last operation you asked, I have made new backup of First boot sector of logical drive and first sector of physical drive with HDHACKER (so it saved 2 files) , and then filled them with 0, and then what to do with those 2 files ?

Save them somewhere for the moment.

The strange thing is that you seemingly have valid data in both the MBR and the PBR, the $MFT is apparently there allright, as seen by dmde, but the filesystem driver fails to mount the volume (both through Imdisk and VDK). :unsure:

I am confused.
Try another thing before anything else (on the "my500GB.img").
Open it with DMDE, does it show a window titled "Partitions - dmde 2.4.4"?
Can you see two entries in it, the first one being:
Image:<path>\my500GB.img etc.
and the second:
<label> Primary (A) NTFS (07) 500 GB EBCF 63 <some number>
?
If yes, if you select the second the "Open Volume" button should become enabled, press it.
A new popup should appear, titled "Open NTFS volume" with some data (post this data).
Then press "Open" button.
This way DMDE is using the data coming from the MBR and PBR (and not the results of the NTFS search).
In the lower right pane you should see (first line):
LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)

If you open again the image, and this time you choose instead "NTFS Search" (start it and wait until "NTFS 0" appears, then press "start/stop") and then select the "NTFS0" and click on the "Open volume" you should get the same:

In the lower right pane you should see (first line):
LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)


If this is what happens, I am wondering what prevents the NTFS mounting with both IMDISK and VDK. :w00t:

jaclaz

#29
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag

Yep, the begin offset is 63 allright but those data do not make much sense.
They are not the actual data related to a file, those correspond to entry #531 in the $MFT, possibly the $MFT entry for that file, according to the data till now gathered.
In the "upper right" pane right click on the file name, you will have a set of choices, right now you seem like having chosen "Open MFT file (hex Editor)", while you want to choose the bolded "Open (Hex Editor)".
Can you see in the lower right pane the beginning of the file?
If yes, you will also see the LBA, vol.sec, Cluster and sec. of the actual file.
Is this file recoverable?


hi,
I've done the OPEN (Hex Editor) last time, and I've seen the beginning of the file on the lower right pane. This small text file was recovered with success :yes: (but not interesting for me !)
the values I've given yesterday were from this file.

Try another thing before anything else (on the "my500GB.img").
Open it with DMDE, does it show a window titled "Partitions - dmde 2.4.4"?
Can you see two entries in it, the first one being:
Image:<path>\my500GB.img etc.
and the second:
<label> Primary (A) NTFS (07) 500 GB EBCF 63 <some number>
?
If yes, if you select the second the "Open Volume" button should become enabled, press it.
A new popup should appear, titled "Open NTFS volume" with some data (post this data).

values are:
Bytes per sector:512
Bytes per cluster:4096
Bytes per MFT record:1024
Bytes per index record:4096
Total sectors number: 976768002
MFT cluster (or 0): 786432
MFTMirr cluster (or 0): 61048000
Start Offset: 32256

when I click open , I've a choice:
Volume does not fit into device:
Use this virtual volume size (this is what I've selected)
or
Use decreased volume size
the values from first line are, as you've said:
LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)

If you open again the image, and this time you choose instead "NTFS Search" (start it and wait until "NTFS 0" appears, then press "start/stop") and then select the "NTFS0" and click on the "Open volume" you should get the same:

In the lower right pane you should see (first line):
LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)


If this is what happens, I am wondering what prevents the NTFS mounting with both IMDISK and VDK. :w00t:


yes it's the same values on first line
thanks for your help

#30
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

when I click open , I've a choice:
Volume does not fit into device:
Use this virtual volume size (this is what I've selected)
or
Use decreased volume size

This is the whole point. :yes:

The total sectors in the structure is

Total sectors number: 976768002

hence the filesystem expects to have:
(976768002+1+63)=976768066*512=500105249792
but the image you reported making is LARGER than that (so the volume should "fit" :unsure: ):

- mksparse <path>\my500GB.img 500105281536:


Can you check (right click in explorer and select properties or do a DIR in a command window) the EXACT size of the image ?
Possibly (and for *any* reason) it is actually smaller than the previously stated.

jaclaz

Edited by jaclaz, 05 November 2012 - 02:03 PM.


#31
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
size of image is 500 105 217 024 bytes

#32
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

size of image is 500 105 217 024 bytes

HOW can this have happened?
You posted:

so, here is what I've done for this grown image:
- datarescuedd the faulty drive in a single image of all sectors (with a lot of reading errors)
- mksparse <path>\my500GB.img 500105281536
- dsfi <path>\my500GB.img 0 0 <path>\thewhatever136GB.img

re-do, this time make sure that the resulting sparse image is actually 500105281536 or slightly more than that.

jaclaz

Edited by jaclaz, 06 November 2012 - 04:39 AM.


#33
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
:blink:
don't know why the size was wrong.
I've redone it, it's now clearly 500 105 281 536 bytes
I've passed again testdisk on it, with same results as before: can see only one directory, and content is empty.
I've tried to mount with IMDisk this new made image my500GB.img, and still same result:

I've mounted it with IMDisk, with default parameters of size of virtual disk, etc. It showed a new letter, but impossible to browse this letter ! (no filesystem type indicated in IMDisk, and windows can't see the size of partition, file or directory unreable or corrupted ...) :realmad:
so, can't get fileextents to work on it too.

??
thanks



#34
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

:blink:
don't know why the size was wrong.
I've redone it, it's now clearly 500 105 281 536 bytes
I've passed again testdisk on it, with same results as before: can see only one directory, and content is empty.
I've tried to mount with IMDisk this new made image my500GB.img, and still same result:

But you can still open it in DMDE , this time being NOT propmpted with:

Volume does not fit into device:
Use this virtual volume size (this is what I've selected)
or
Use decreased volume size

and see the $MFT contents with it?

Since (the good thing is) that the image is a "copy", we can play a bit with it.
What happens if you mount it in IMDISK , open a command prompt and run in it:
CHKDSK F:
(provided that the drive letter assigned by IMDISK is F:, of course)?

But BEFORE that, can you check it again in TESTDISK, and do three things:
  • do a log of the session
  • check/verify/fix the $MFT Mirror
  • post the actual log

jaclaz

#35
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag

But you can still open it in DMDE , this time being NOT propmpted with:

Volume does not fit into device:
Use this virtual volume size (this is what I've selected)
or
Use decreased volume size

and see the $MFT contents with it?

yes, there is no more prompted message
on the lower right pane, I can see "FILE:$MFT" with all information about $FILE_NAME, $DATA,$BITMAP, ....

But BEFORE that, can you check it again in TESTDISK, and do three things:

  • do a log of the session
  • check/verify/fix the $MFT Mirror
  • post the actual log

jaclaz

under testdisk, I've just searched for partition, display files (only display one empty directory) and that's all
I've attached the log
did you want other actions in testdisk ? I don't understand which action you mean on checklist #2
thanks

Attached Files



#36
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

under testdisk, I've just searched for partition, display files (only display one empty directory) and that's all
I've attached the log
did you want other actions in testdisk ? I don't understand which action you mean on checklist #2
thanks

You see, in the log there is:

NTFS filesystem need to be repaired.

ntfs_readdir failed


Now we do know (from the PBR/bootsector) that the $MFT mirror is on cluster 61048000, i.e. 61048000*4096=250052608000 (given or taken the few sectors before) i.e. around 250 Gb, i.e. well beyond your "good" 134 Gb, so in practice thre is NO $MFT mirror.

Actually - on a "normal" image it should be there (in the worst case) as all 00's BUT you have a sparse 500Gb image, so the $MFT Mirror actually doesn't exist at all. (I hope I make some sense to you now, a sector in a sparse file does not exist until something actually performs an operation on that sector).

This may be connected (or may be not) with the Windows IFS driver incapable to recognize the NTFS volume (error you have in IMDISK) and with the TESTDISK log (though it may be only PART of the issue).

The idea is to first thing use TESTDISK to create a new $MFTMirror from the actual $MFT, see here:
http://www.cgsecurit..._and_MFT_Repair

Repair An NTFS MFT

The MFT (Master File Table) is sometimes corrupted. If Microsoft's Checkdisk (chkdsk) failed to repair the MFT, run TestDisk. In the Advanced menu, select your NTFS partition, choose Boot, then Repair MFT. TestDisk will compare the MFT and MFT mirror (its backup). If the MFT is damaged, it will try to repair the MFT using the backup. If the MFT backup is damaged, it will use the main MFT.

before attempting running CHKDSK.

jaclaz

#37
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
I've done testdisk, Advanced Menu, Boot, and then Org.BS
it wrotes backup sector with the original sector
then I've made "Repair MFT", it wrotes the Mirror MFT with original MFT

I have the same problem mounting with IMDriver, no success under windows explorer

should I run a chkdsk now ?
thanks

#38
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

should I run a chkdsk now ?

Yes. :)
Run it at first without parameters, then - again - with /F parameter and then - again - with the /R parameter.
Let's see what happens. :unsure:

jaclaz

#39
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
ok, first checkdisk without parameters returns a lot of messages like this one (sorry it's translated from french):
errors corrected in index $I30 of file 42062
....
index verification terminated
errors found. chkdsk can not continue in read only mode

Then, with /F, a lot of messages like this:
errors corrected in index $I30 of file 41863
Sort of index $I30 of file 41863
Restore of orphaned file xxxx.xxx (1198) in file of directory 49
Insert of index entry with ID 311 in index $SDH of file 9
Fix of record segment of security file
...
Errors corrected in miror of MFT
Errors corrected in "capslock" file
errors corrected in bitmap attribute of MFT
errors corrected in volume map

and finally with /F /R:
everything was ok

Then, I can see the directory and files under windows !! :thumbup
but of course, still unable to read the dozen of files I'm interested in.
should I give a try with the extents now ? (from your procedure in a previous post)
thanks a lot

#40
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

Then, I can see the directory and files under windows !! :thumbup
but of course, still unable to read the dozen of files I'm interested in.
should I give a try with the extents now ? (from your procedure in a previous post)
thanks a lot

Yep :thumbup:

You may want to redirect the output of running getfileextents to a file, so that you have a list of the offsets (it would be a good idea to later use a spreadsheet to make a list of them.
A simple batch may be of use (make a directory C:\GFE\ and save this as GFE.CMD :
@ECHO OFF
SETLOCAL ENABLEDELAYEDEXPANSION
Set File=%~dpnx1
ECHO FOffset: LBA:     Sectors: File	
FOR /F "tokens=3,5,7 delims=: " %%A IN ('getFileExtents.exe "%File%"') DO (
CALL :octify Foffset %%A
CALL :octify LBA %%B
CALL :octify Sectors %%C
ECHO !Foffset! !LBA! !Sectors! %File%
ECHO !Foffset! !LBA! !Sectors! %File%>>gfelog.log
)
ECHO.>>gfelog.log
GOTO :EOF

:octify
SET %1=0000000%2
SET %1=!%1:~-8,8!
GOTO :EOF
depending on the spreadsheet and local settings you use, you can replace the spaces in the line:
ECHO !Foffset! !LBA! !Sectors! %File%>>gfelog.log
with either [TAB] or [COMMA] or [SEMICOLON]

jaclaz

Edit: Typo in the batch. "Good" version attached (just in case)
Edit2: Added as attachment gfedec.zip, that directly outputs decimal data instead of Hex

Attached Files


Edited by jaclaz, 08 November 2012 - 06:48 AM.


#41
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
sorry, but how to use your batch ?
gfe.cmd driverletter: ??

thanks

#42
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

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

#43
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
GetFileExtents always returns me this error:
initFileTranslation: invalid descriptor

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

:huh:

#44
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

GetFileExtents always returns me this error:
initFileTranslation: invalid descriptor

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

:huh:

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

#45
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
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 ? :yes:
thanks a lot

#46
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

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

Attached Files



#47
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag
here we go with your magic batch ! :thumbup

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

#48
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

here we go with your magic batch ! :thumbup

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 :ph34r: .
Which could mean that your image already contains some corruprted sector :unsure:

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:

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

#49
onlit4regs

onlit4regs

    Newbie

  • Member
  • 35 posts
  • OS:XP Pro x86
  • Country: Country Flag

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

#50
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,385 posts
  • OS:none specified
  • Country: Country Flag

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN