23 replies to this topic

[bilou_gateux]

My goal: backup only 3rd partition with free tools.

branded computer with OS (Windows 7) preload.

 

1 [SYSTEM] partition

2 [OS] partition

3 [HP_RECOVERY] partition

4 [HP_TOOLS] partition

 

plpart32

disk partition layout:

 

PLPPART32 v0.1  20070403  by Elmar Hanlhofer  http://www.plop.at

Using physical drive 0

Drive geometry:

  Media Type         : FixedMedia
  Cylinders          : 60801
  Tracks per Cylinder: 255
  Sectors per Track  : 63
  Bytes per Sector   : 512

NR  ID  BOOT     SS  SH   SC    ES  EH   EC     LBAST    LBASEC  SIZE
-------------------------------------------------------------------------------
1  0x07 *[0x80]  33  32     0   19 223    12      2048    204800 100.00 MByte
2  0x07          20 223    12   63 254  1023    206848 955467776 455.60 GByte
3  0x07          63 254  1023   63 254  1023 955674624  20889600 9.96 GByte
4  0x27          63 254  1023   63 254  1023 976564224    206848 101.00 MByte

I started trying to backup the small 1st partition

 

dsfo 204800 sectors x 512 = 104857600 bytes

dsfo \\.\PHYSICALDRIVE0 2048 104857600 SYSTEM.IMG

 

mounting with PassMark OSFMount without issue.

 

mount as ImDisk virtual disk:

image mounted but File System not detected

the disk in drive X: is not formatted

 

then i tried backup from the start offset 0 of physical disk.

dsfo \\.\PHYSICALDRIVE0 0 104857600 SYSTEM_start0.IMG

 

mounting with PassMark OSFMount ask to select partition to mount from 4 primary partitions. Select 1st

image file offset: 2048

drive size: 204800

mount OK

 

mount as ImDisk virtual disk:

select partition in disk image

Primary partition 1 - 100MB NTFS or HPFS

image file offset: 2048

drive size: 204800

mount OK

 

can someone explain how to backup 3rd partition and parameters to use with dsfo.

i would like to mount image with both imdisk or OSFMount.

 

 

 

 

 

 

[Wonko the Sane]

can someone explain how to backup 3rd partition and parameters to use with dsfo.

i would like to mount image with both imdisk or OSFMount.

You cannot (directly).

The issue is that dsfo when the source is a PhysicalDrive is "forced" to have a 0 offset (start).

From the read-me:

 

 

The offset argument has to be "0" with non-file objects

 

You can use another tool (that can have non-0 offsets) though.

Or access the Volume instead. (after having separately backed up the MBR and hidden sectors - if needed)

 

BUT (haven't tested ) you might find in the case of NTFS that the last sector of the partition (actually fiirst sector outside the Volume) i.e. the mirror of the bootsector will not be imaged.

So you need to re-assemble:

1. the MBR (and correct partition data in it)
2. the hidden sectors (if needed)
3. the imaged Volume (correcting "sectors before" in the PBR)
4. if my suspect is right , add a copy of the first sector of the Volume at the end

 

 

Wonko

.

[bilou_gateux]

Or access the Volume instead. (after having separately backed up the MBR and hidden sectors - if needed)

 

BUT (haven't tested ) you might find in the case of NTFS that the last sector of the partition (actually fiirst sector outside the Volume) i.e. the mirror of the bootsector will not be imaged.

Wonko

.

Thanks for the clarification.

 

I've noticed the issue with last sector of the partition when using command:

dsfo \\.\e: to backup volume.

 

from the source

The NTFS Boot Record's "Backup Sector"

 

OSFMount is able to mount raw image of volume though.

 

So you need to re-assemble: the MBR (and correct partition data in it) the hidden sectors (if needed) the imaged Volume (correcting "sectors before" in the PBR) if my suspect is right , add a copy of the first sector of the Volume at the end

If i save the "backup sector" to a file with a tiny hex editor, i should be able to assemble both parts (volume raw image+ backup sector image).

[Wonko the Sane]

If i save the "backup sector" to a file with a tiny hex editor, i should be able to assemble both parts (volume raw image+ backup sector image).

 

Why?

You can use dsfo allright.

The general idea of a backup bootsector is that it is an EXACT copy of the bootsector.

Make a copy of the "real" bootsector INSTEAD and call it "backup bootsector"

 

You have TWO possibilities:

1. the current backup of the bootsector is NOT identical to the current bootsector (and then something is WRONG AND needs to be corrected - guess HOW? by copying the current bootsector -after having verified it - over it's backup copy)
2. the current backup of the bootsector IS identical to the current bootsector (and then there is no difference between making a copy of it and making a copy of the current bootsector)

The "tricky" part is that of "fixing" the addresses in both the partition table AND BOTH copies of the bootsector to reflect the layout of the "new, reduced disk image where third partition has become first one" that is IF you wish to keep the MBR and hidden sectors, something that "normally" wouldn't provide much advantages BUT that in the case of a stupid HP recovery partition is "vital" as the MBR is not only non-standard but seemingly "specially crafted" for the original disk, see:

http://www.msfn.org/...-not-be-found/

[bilou_gateux]

Just for the record:

when trying to mount the HP_RECOVERY volume (dsfo backup) with OSFMount,

i get message:

 

The image file size is smaller than the size of NTFS partition and may not mount correctly in Windows.
Do you want to auto-correct this?

 

I hit Yes to correct disk size.

 

 

I will try to summarize what i would like to do:

 

Have a backup of vital data in case of physical hard drive failure.

Under warranty, manufacturer will send us a replacement part (same size drive but OEM manufacturer could be different, WD versus HGST versus SEAGATE).

 

User should not have important data on user partition (OS), all data should be stored elsewhere (network or cloud).

 

After replacing hard drive, i will restore 1st sector (containing special manufacturer MBR, disk signature and partition table)+ 63 following sectors (hidden data stored by the manufacturer used for recovery purpose), restoring recovery partition (including NTFS volume and backup boot sector). After that, i will reboot and hit the special manufacturer key at POST to boot from WinRE stored on recovery partition and launch factory restore tool.

 

You're right about backup boot sector, it should be the same as the original!

 

I just want to make the process the less user interaction and with command line tool at console prompt.

 

1/ mount new hard drive

2/ boot from WinPE UFD

3/ restore sectors 0-63

4/ restore recovery partition (both volume and backup boot sector)

5/ reboot and hit Manufacturer key at POST to restore factory OS install.

 

I do not plan to change partition layout, i will keep 4 primary partitions and keep same size as factory for each one.

 

I already done that with mix of:

free tools (dsfo, mbrfix, plppart32) to backup/restore sectors 0-63

licensed tool (ghost32) to backup/restore recovery partition.

now i want to use a free tool instead of Symantec tool (custom manufacturer licenced version with only restore ability)

[Wonko the Sane]

I hit Yes to correct disk size.

And what happens if you DO NOT click Yes to correct size?

 

There are two possible approaches to what you want to do (final goal):

1. image/save the sectors 0÷63 and the recovery partition AND having a way to mount/access/inspect this image/backup
2. image/save the sectors 0÷63 and the recovery partition BUT NOT having a way to mount/access/inspect this image/backup

All the "difficulties" are with the AND in #1 above.

I.e. you need for that an "intermediate" step or "special image format" that is also accessible through OFS or IMDISK (or whatever)

 

Additionally there are two approaches to the imaging, you can do either "forensic sound" imaging or "just image what is needed" (this latter in order to reduce as much as possible the size of the image (of course for this latter some tests are needed to see WHAT is actually needed, very possibly *nothing* except MAYBE the volume serial or the volume label or both of them )

 

Basically this (#1 above) would be, assumed that disk is \\.\PhysicalDrive1 and recovery volume is mounted as letter R:\ and that backup media is mounted as M:\:

 

dsfo \\.\PhysicalDrive1 0 32256 M:\from0_to_63.dat

dsfo \\.\R: 0 0 M:\the_recovery_partiton.dat

dsfo \\.\R: 0 512 M:\the_bootsector_of_the_recovery_partiton.dat

dsfo M:\the_recovery_partiton.dat -512 512 M:\the_backup_bootsector_of_the_recovery_partiton.dat

fc /b M:\the_bootsector_of_the_recovery_partiton.dat:M:\the_backup_bootsector_of_the_recovery_partiton.dat <- this is only to make sure

IF FC finds no differences you are all set, if it finds them:

del M:\the_backup_bootsector_of_the_recovery_partiton.dat

copy /b M:\the_bootsector_of_the_recovery_partiton.dat M:\the_backup_bootsector_of_the_recovery_partiton.dat

dsfi M:\the_recovery_partiton.dat e 0 M:\the_backup_bootsector_of_the_recovery_partiton.dat

 

To restore:

dsfi \\.\PhysicalDrive1 0 32256 M:\from0_to_63.dat

let the system mount the partitions and assign them drive letters, let say that the partition where the recovery is to be restored is drive E:\:

dsfi \\.\E: 0 0 M:\the_recovery_partition.dat

 

To mount (to access temporary or whatever):

copy /b M:\the_bootsector_of_the_recovery_partiton.dat M:\the_bootsector_of_the_recovery_partition_BUT_with_0_sectors_before.dat

dsfo M:\the_bootsector_of_the_recovery_partiton.dat 16 4 M:\4_nice_digital_0s.dat

dsfi M:\the_bootsector_of_the_recovery_partition_BUT_with_0_sectors_before.dat 28 4 M:\4_nice_digital_0s.dat

dsfi M:\the_recovery_partiton.dat 0 512 M:\the_bootsector_of_the_recovery_partition_BUT_with_0_sectors_before.dat

here you can mount it with IMDISK

to restore as before:

dsfi M:\the_recovery_partiton.dat 0 512 M:\the_bootsector_of_the_recovery_partition.dat

 

Of course, use some less ridiculous filenames .

 

You will need to check that when the partition image is temporarily modified to be mounted in IMDISK the "real" bootsector being different from the "backup" one makes this latter get synchronized, but it is a win-win situation:

• IF it is synchroniized, then it will be also synchronized when you mount the restored partition (and you need not to worry as the data there will become valid)
• IF it is NOT synchronized, then it will also be NOT synchronized when you mount the restored partition (and you need not to worry as the data there is already valid)

 

 

Wonko

[bilou_gateux]

bilou_gateux, on 21 Jan 2013 - 15:20, said: I hit Yes to correct disk size. And what happens if you DO NOT click Yes to correct size?

Same issue as trying to mount image with ImDisk.

image mounted but File System not detected

 

the disk in drive X: is not formatted

 

 

 

Additionally there are two approaches to the imaging, you can do either "forensic sound" imaging or "just image what is needed" (this latter in order to reduce as much as possible the size of the image (of course for this latter some tests are needed to see WHAT is actually needed, very possibly *nothing* except MAYBE the volume serial or the volume label or both of them ) Basically this (#1 above) would be, assumed that disk is \\.\PhysicalDrive1 and recovery volume is mounted as letter R:\ and that backup media is mounted as M:\:

 

 

 

NR    partition        sector[hex]    sector[dec]    offset
1    ST    0x800        2048        1048576
1    LS    0x327FF        206847

2    ST    0x32800        206848        105906176
2    LS    0x38F66FFF    955674623

3    ST    0x38F67000    955674624    489305407488
3    LS    0x3A352FFF    976564223    500000882176

4    ST    0x3A353000    976564224    500000882688
4    LS

 

 

 

Here's my step by step approach:

backup 0-63 hidden sectors

dsfo \\.\PhysicalDrive1 0 32256 M:\0-32256.img

 

backup 1st sector [512 bytes] including MBR + partition table from 0-63 sectors img above

dsfo M:\0-32256.img 0 512 M:\0-512.img

 

backup partition table data from 1st sector img above

dsfo M:\0-512.img 446 66 M:\446-512.img

 

backup 3rd partition NTFS boot sector

dsfo \\.\PhysicalDrive1 489305407488 512 M:\p3ntfsbs.img

 

backup 3rd partition NTFS boot sector backup

 

dsfo \\.\PhysicalDrive1 500000882176 512 M:\p3ntfsbbs.img

 

compare M:\p3ntfsbs.img <> M:\p3ntfsbbs.img

 

fc /b M:\p3ntfsbs.img M:\p3ntfsbbs.img

 

Comparing files p3ntfsbs.img and p3ntfsbbs.img

FC: no differences encountered

 

 

backup 3rd volume (forensic method)

dsfo \\.\R: 0 0 M:\HP_RECOVERY.img 

 

../..

 

next step:

read again Wonko the Sane suggestions

wait input from Olof. What ImDisk should find inside image to detect partition layout and mount it.

I would like to build an image i can mount with ImDisk (explorer right click) or from command line.

OSFMount can mount it but i must acknoledge the smaller image file size, not fully automated...

[bilou_gateux]

1/ another command to backup the 3rd partition:

start sector of 3rd partition: offset = 489305407488

size 20889600 sectors * 512 = 10695475200

dsfo \\.\PhysicalDrive1 489305407488 10695475200 M:\10444800.img

10444800.img = 10444880 KB = 10695475200

I can mount this image without error message (about incorrect size) using OSFMount GUI or command line

OSFMount.com -a -t file -f M:\10444880.img -m #:

 

 

I can mount as ImDisk Virtual Disk (right click from explorer) but Windows [Select partition Image] Popup:

Use entire image file

> OK <

or command line

imdisk.exe -a -t file -f M:\10444880.img -m #:

 

2/ another command using Olof rawcopy small command line utility

rawcopy.exe -m:2M -d \\.\R: M:\RAWCOPY.img

rawcopy.img = 10444880 KB = 10695475200

mount image

OSFMount.com -a -t file -f M:\rawcopy.img -m #:

or

imdisk.exe -a -t file -f M:\rawcopy.img -m #:

OK in both cases.

 

What else?

 

DSFO command seems faster than RAWCOPY command. I should try again to compare time needed to backup.

 

Conclusion

volume backup using command below don't give us usable file for mounting as virtual image with command line tools.

dsfo \\.\R: 0 0 M:\HP_RECOVERY.img

 

HP_RECOVERY.img = 10444796 KB = 10695471104 10695475200 minus 10695471104 EQU 4096 DIVIDED BY 512 EQU 8 missing sectors?

[Wonko the Sane]

@bilou

It seems to me you have missed the part where the "sectors before" are corrected in the PBR.

 

You have TWO choices:

1. assemble a MBR (with corrected partition table values) + 62 hidden sectors + Volume image (WITH PBR corrected with sectors before=63) <- more complex
2. use just the Volume image (WITH PBR corrected with sectors before=0) <- more simple AND detailed in my previous post

In first case IMDISK will access/mount the thingy as a Volume inside hard disk image, in second case it will mount it directly as Volume (as if it were a super-floppy).

 

Can you try this EXACT sequence of commands? (this is #2 above)

 

 

 

dsfo \\.\R: 0 0 M:\HP_RECOVERY.img
dsfo \\.\R: 0 512 M:\p3ntfsbs.img
copy /b M:\p3ntfsbs.img M:\p3ntfsbs0000.img
dsfo M:\p3ntfsbs.img 16 4 M:\4_nice_digital_0s.dat
dsfi M:\p3ntfsbs0000.img 28 4 M:\4_nice_digital_0s.dat
dsfi M:\HP_RECOVERY.img 0 512 M:\p3ntfsbs0000.img

 

 

 

And try mounting M:\HP_RECOVERY.img with IMDISK?

 

Wonko

 

EDIT:

No , actually IMDISK ignores the sectors before (or auto-corrects them for mounting in the case of a super-floppy) so this is NOT the issue.

Here a command equivalent to:

 

 

dsfo \\.\R: 0 0 M:\HP_RECOVERY.img

 

works allright.

There must be something "wrong" in the source.

 

 

HP_RECOVERY.img = 10444796 KB = 10695471104 10695475200 minus 10695471104 EQU 4096 DIVIDED BY 512 EQU 8 missing sectors?

 

Post the MBR and the bootsector of the 3rd partition, it is possible that there is an issue with partition size (MBR) when compared to sectors in filesystem (PBR)....

[bilou_gateux]

benchmarks:

dsfo \\.\PhysicalDrive1 489305407488 10695475200 M:\10444800.img
Duration: 00:09:55,54

rawcopy.exe -m:2M -d \\.\R: M:\RAWCOPY.img
Duration: 00:10:25,36

dsfo \\.\R: 0 0 M:\HP_RECOVERY.img

Duration: 00:09:07,17

 

 

Post the MBR and the bootsector of the 3rd partition, it is possible that there is an issue with partition size (MBR) when compared to sectors in filesystem (PBR)....

 

 

I will attach zip archive with the two files asked. switching to full editor...

 

 

 

dsfo \\.\PhysicalDrive1 0 512 MBR_512.img
dsfo \\.\PhysicalDrive1 489305407488 512 P3ntfsBS.img

Attached Files

•  files.zip   1.19K   49 downloads

[Wonko the Sane]

Since you are benchmarking, try dd for windows (use bs=1M) it should be a tadbit faster than dsfo (if you use the "standard" bs=512 it will "take forever")
http://www.chrysocome.net/dd


Wonko

[bilou_gateux]

Since you are benchmarking, try dd for windows (use bs=1M) it should be a tadbit faster than dsfo (if you use the "standard" bs=512 it will "take forever")
http://www.chrysocome.net/dd


Wonko

benchmark:

dd if=\\.\R: of=M:\DD_RECOVERY.img bs=1M
Duration: 00:11:18,74

 

DD_RECOVERY.img = 10444796 KB = 10695471104

HP_RECOVERY.img = 10444796 KB = 10695471104

 

same behavior trying to mount image created with dd as image created with dsfo volume backup:

incorrect size reported by OSFMount.

[Wonko the Sane]

Well, something is clearly "queer".
 
The MBR and PBR data are OK.

The MBR partition table lists a size of 20,889,600 sectors.
The PBR lists a number of sectors in the filesystem of 20,889,599 which is correct, as 20,889,599+1=20,889,600).

An image should be either of:
20,889,600*512=10,695,475,200 <- including the "extra" backup bootsector outside the Volume/filesystem BUT inside the partition
20,889,599*512=10,695,474,688<- ONLY the Volume/filesystem (as if it was a "superfloppy")
 
10,695,475,200-10,695,471,104=4,096 = 8 sectors = 1 cluster
10,695,474,688-10,695,471,104=3,584 = 7 sectors = almost 1 cluster
 
Idea (only an idea): it depends from this:

• the size of the partition size is exactly divisible by 8 (size of clusters in the NTFS partition)
• obviously the size of the volume is -1 bytes and thus it is NOT divisible by 8
• *something* in the *whatever* chain that mounts/assigns the drive letter rounds down the size to an even number of clusters.
• when you access the object as "drive letter" this less by one cluster size is used

Which OS are you running?
Could it be a quirk of 7 (if you were doing these tests in 7)?
 
I will try to reproduce in XP, to see if it's an OS issue, a "one time only" bug specific to number 20,889,599 or something else (but I need to get a suitable hard disk that I can fiddle with, so it will take some time).
 
Can you try another couple experiments in the meantime?
 
 
Let us try to "bypass" the drive lettering mechanism.

Run Mountvol and "unassign" the R:\ drive letter from that Volume.
Use the VLM found ID for the volume:
 
 
 

To backup a "hidden" partition (no assigned letter), first run vlm to find its
unique volume name, then copy and paste it to dsfo, eg:
dsfo \\.\Volume{ac837e69-551d-11d9-9a3c-806d6172696f} 0 0 c:\tmp\my.dat

Is the image still the same (wrong) size?
 
Try dd --list.
Use the syntax *like*:
 

dd if=\\?\Device\Harddisk1\Partition3 of=M:\HP_recovery.img bs=1M

 

 
and the same, but adding the --size parameter:
 

 

dd if=\\?\Device\Harddisk1\Partition3 of=M:\HP_recovery.img bs=1M --size

 

Any difference?
 

Wonko

[bilou_gateux]

Which OS are you running? Could it be a quirk of 7 (if you were doing these tests in 7)?

 

PhysicalDrive1: target disk with Windows 7 Pro factory OS preload installed

target box:= boot from WinPE 1.6 (MOA build 2003 Server SP1 binaries) UFD

http://sanbarrow.com/moa.html

 

 

vlm v1.00, Freeware - use at your own risk
©2005 Dariusz Stanislawek, http://freezip.cjb.net/freeware

Found volumes:

>DATA listed here removed< related to PhysicalDrive0:

\\.\Volume{7fc80a7f-6419-11e2-907a-806e6f6e6963}
Label: SYSTEM, File System: NTFS  99/75 MB
Symbolic Link: \Device\HarddiskVolume3

\\.\Volume{7fc80a80-6419-11e2-907a-806e6f6e6963}
Label: OS, File System: NTFS  466536/439829 MB
Symbolic Link: \Device\HarddiskVolume4

\\.\Volume{7fc80a81-6419-11e2-907a-806e6f6e6963}
Label: HP_RECOVERY, File System: NTFS  10199/1162 MB
Symbolic Link: \Device\HarddiskVolume5

 

 

 

dsfo \\.\Volume{7fc80a81-6419-11e2-907a-806e6f6e6963} 0 0 MY.DAT

MY.DAT size EQU DD_RECOVERY.img size = 10444796 KB = 10695471104

same wrong size

 

I will report dd test tomorrow

[Wonko the Sane]

I have some good news and some bad news.

 

The good news are that the behaviour is replicable on XP AND that my guess was right (it is actually connected with cluster size).

 

The bad news are that the "quirk" is there and it is at a "lower" level than I expected.

 

It seems like *somehow* Windows when mounting the disk checks the bootsector of the NTFS partition and "subtracts" from the size a whole cluster.

 

I have to do some more tests, but the essence is that one.

 

Quick test (replicable):

Create a new volume in IMDISK, sized 10 Mb (10.485.760 bytes or 20480 blocks), say that is mounted as T:\.

Format it as NTFS (set cluster size to 512 bytes), then dd if=\\.\T: of=D:\TEST.img

 

20479+0 records in
20479+0 records out

 

re-format it with cluster size 1024, then dd if=\\.\T: of=D:\TEST.img

20478+0 records in
20478+0 records out

 

re-format it with cluster size 2048, then dd if=\\.\T: of=D:\TEST.img

20476+0 records in
20476+0 records out

 

re-format it with cluster size 4096, then dd if=\\.\T: of=D:\TEST.img

20472+0 records in
20472+0 records out

 

Starting to see a pattern ...

 

Wonko

 

P.S.: I knew I had found something similar in the past , here it is:

http://www.911cd.net...ic=24353&st=240

NFGdump could be another little thingy to test again.

[bilou_gateux]

The Finder, nothing else.

You have a faculty for fact-finding that serves us well.

 

 

 

nfgdump dump /v /p /c /g /d=R: /f=M:\nfgd_RECOVERY.img

 

 

 

NTFS volume characteristics:

 

base offset ................................... : 489.305.407.488 [455.70 GB]

volume size (partition table) ..... : 10.695.475.200 [9.96 GB]

reported volume size (NTFS) ... : 10.695.474.688 [9.96 GB]

backup boot sector(s) ............. . : present

sector size ................................... : 512

cluster size .................................. : 4.096

MFT record size .......................... : 1.024

INDEX record size ...................... : 4096

sectors [clusters] ........................ : 20.889.592 [2.611.199]

 

Backup initialisation finished, 9.476.874.240 (8.83 GB) about to be dumped.

 

Duration: 00:28:06,84

Image is not a raw copy of partition, contains only DATA, not empty sectors

Size: 9 477 200 796 bytes

[Wonko the Sane]

Yep, but the issue with NFGdump (besides the fact that it images only indexed data, which in your specific case could be good - as long as you don't need/want to access the backup until restore) is - as you have found out by testing - that it is extremely slow (when compared to dsfo which is not in itself a champion of speed).

 

When using 7 there may be a "simple" way out, basically backing up just the bootsector of \.\R:\, then zeroing it, put the disk offline and then back online (through diskpart) before backing up the whole \\.\R:\ (and afterwards restore the original bootsector over the zeroed one).

It seems that is the *whatever stupid automagic* feature of Windows fails to detect a "recognized" bootsector, then the data in the MBR is trusted (as it should alway be).

 

Can you try the above? 

 

I will do more experiments, most probably instead of downright zeroing the bootsector (which is however easy since we just fsz a 512 byte zeroed file and deploy it with dsfi) some minor modification might do as well.

And I want to check with other filesystems besides NTFS.

As a matter of fact there is not a *need* to put the disk offline and then online again, all it is needed is a way to "refresh the mounting" (just like it happens when you format a volume) but right now I cannot remember any tool/command that may do the same.

 

Wonko

[bilou_gateux]

When using 7 there may be a "simple" way out, basically backing up just the bootsector of \.\R:\, then zeroing it, put the disk offline and then back online (through diskpart) before backing up the whole \\.\R:\ (and afterwards restore the original bootsector over the zeroed one). It seems that is the *whatever stupid automagic* feature of Windows fails to detect a "recognized" bootsector, then the data in the MBR is trusted (as it should alway be).

 

 

fsz %temp%\dummy.img 512
dsfi \\.\PhysicalDrive1 489305407488 512 %temp%\dummy.img
echo/select disk 1 >%temp%\rescan.txt
echo/rescan>>%temp%\rescan.txt
echo/exit>>%temp%\rescan.txt
diskpart /s %temp%\rescan.txt
dsfo \\.\R: 0 0 M:\DUM_RECOVERY.IMG
dsfi \\.\PhysicalDrive1 489305407488 512 M:\P3ntfsBS.img
diskpart /s %temp%\rescan.txt
dsfi M:\DUM_RECOVERY.IMG 0 512 M:\P3ntfsBS.img
imdisk.exe -a -t file -f M:\DUM_RECOVERY.IMG -m #:

 

DUM_RECOVERY.img = 10444880 KB = 10695475200

 

by giving away your time, your creativity, and the results of your skill,

you already know the answer.

;-)

I get a working image with correct size

NTFS Boot Sector [0-512]+volume data [512-20889599]+NTFS backup boot sector [20889599-20889600]

Total sectors: 20889600 * 512 = 10695475200

 

i can mount it from command line using imdisk.

[Wonko the Sane]

Good .

But still, it does look an AWFUL procedure .

The posted code is essentially "wrong"   (in the sense that you are still needing reading the data from the MBR to get the offset ) and can be replaced by the (using not "absolute" addresses):

 

 

 

dsfi \\.\R: 0 512 M:\P3ntfsBS.img

fsz %temp%\dummy.img 512
dsfi \\.\PhysicalDrive1 489305407488 512 %temp%\dummy.img dsfi \\.\R: 0 512 %temp%\dummy.img
echo/select disk 1 >%temp%\rescan.txt
echo/rescan>>%temp%\rescan.txt
echo/exit>>%temp%\rescan.txt
diskpart /s %temp%\rescan.txt
dsfo \\.\R: 0 0 M:\DUM_RECOVERY.IMG
dsfi \\.\PhysicalDrive1 489305407488 512 M:\P3ntfsBS.img dsfi \\.\R: 0 512 M:\P3ntfsBS.img
diskpart /s %temp%\rescan.txt
dsfi M:\DUM_RECOVERY.IMG 0 512 M:\P3ntfsBS.img
imdisk.exe -a -t file -f M:\DUM_RECOVERY.IMG -m #:

 

At the cost of a MUCH bigger sized program, and possibly with a few simple dependencies to be checked for use in a PE, you could try Clonedisk.

 

Our friend erwan.l is seemingly (I hope momentarily) MIA , but the thingy seems like working consistently and should be in the same speed range as dsfo and dd for windows.

 

Clonedisk does have some command line support that is scarcely, incompletely and "scattered" around , but that do work.

 

The issue is that he did not (yet ) add the provision for the backup bootsector:

http://www.911cd.net...ndpost&p=169352

BUT Clonedisk does the "right math" with the partiion size, AND there is no actual *need* to have the backup bootsector to mount the image in IMDISK, hence:

 

 

clonedisk  -image -backup \\.\R: M:\DUM_RECOVERY.IMG raw

clonedisk -bs -backup \\.\R: M:\P3ntfsBS.img <-OPTIONAL (not needed  for IMDISK mounting)

dsfi M:\DUM_RECOVERY.IMG e 512 M:\P3ntfsBS.img <-OPTIONAL (not needed for IMDISK mounting)

should do nicely.

 

BTW, nice trick the Select Disk in diskpart being enough to "refresh"

 

I did a few tests and the "integral" cluster approach (and the consequent "wrong" size of the image) ONLY happens for NTFS (and NOT for FAT, either 16 or 32).

 

This has some logic (as in NTFS *evrything is a cluster* unlike on FAT) but it is obviously a flawed one.

 

A possibility  is that the good MS guys failed *somehow* in one of the evolution steps of NTFS.

In the good ol' times cluster size was 512 bytes (or 1 sector) AND backup bootsector was in the middle.

Then it was moved outside the filesystem.

The flawed behaviour would not have been noticed as it does NOT apply in the case of a single sector cluster.

It seems like the "rule" is (crazy at it might seem):

• IF the filesystem is NTFS then the actual filesystem will be one sector less than the "declared" size in the MBR, and so we will make accessible one cluster less

Still going to do some more experiments, time permitting ......

 

Wonko

[bilou_gateux]

But still, it does look an AWFUL procedure . The posted code is essentially "wrong" (in the sense that you are still needing reading the data from the MBR to get the offset ) and can be replaced by the (using not "absolute" addresses):  At the cost of a MUCH bigger sized program, and possibly with a few simple dependencies to be checked for use in a PE, you could try Clonedisk.

 

I like your improvements.

only requirement: find assigned drive letter to volume HP_RECOVERY

This letter is predictable searching an always present tag file inside file system. Good for scripting.

 

 

clonedisk -image -backup \\.\R: M:\DUM_RECOVERY.IMG raw

Duration 00:08:53,49

 

Good, Clonedisk performs better than "competitors", OK under WinPE 1.6 2005 MOA build.

 

A question then arises.

 

The well-known manufacturer at factory create 4 partitions.

SYSTEM partition (1st) always as offset 2048 fixed size 100MB

OS partition (2nd) is initialy 40GB

HP_RECOVERY partition is fixed size

HP_TOOLS partition is always the 4th and created with a fixed size, offset computed from the last sector

 

2nd partition is later expanded during initial install at factory to use all available space, whatever size of Hard Drive (500GB, 750GB, 1TB, etc...)

as a result, the 2rd partition total sectors not a multiple of 4096, nor the 4th (FAT32)

204800 / 4096 = 50

955467776 / 4096 = 233268,5

20889600 / 4096 = 5100

 

Good idea (or not) to follow robertcollier4 suggestions in PartitionGuru thread when re-creating partitions from scratch.

 

Any recommendations?

[Wonko the Sane]

I like your improvements.
only requirement: find assigned drive letter to volume HP_RECOVERY
This letter is predictable searching an always present tag file inside file system. Good for scripting.

And you can use (and abuse) dd --list or the code in the corresponding batches ddlist.cmd and ddlistw.cmd:
http://reboot.pro/to...st-and-ddlistw/
to check for partition number, etc.

 
A question then arises.
 
The well-known manufacturer at factory create 4 partitions.
SYSTEM partition (1st) always as offset 2048 fixed size 100MB
OS partition (2nd) is initialy 40GB
HP_RECOVERY partition is fixed size
HP_TOOLS partition is always the 4th and created with a fixed size, offset computed from the last sector
 
2nd partition is later expanded during initial install at factory to use all available space, whatever size of Hard Drive (500GB, 750GB, 1TB, etc...)
as a result, the 2rd partition total sectors not a multiple of 4096, nor the 4th (FAT32)
204800 / 4096 = 50
955467776 / 4096 = 233268,5
20889600 / 4096 = 5100
 
Good idea (or not) to follow robertcollier4 suggestions in PartitionGuru thread when re-creating partitions from scratch.
 
Any recommendations?

To do what?
Create aligned partitions?
You can use (or abuse) the code in Mbrbatch.cmd:
http://reboot.pro/?showtopic=3191
as well.
BUT we must again separate NTFS from FAT (both 16 and 32).
NTFS is "inherently aligned", i.e. as long as the partition is aligned, the filesystem will also be.
FAT 16 and 32 are not.
You need to either choose a non-aligned partition address to align a "default formatted" filesystem OR have the partition aligned and correct/modify the filesystem in such a way that it is aligned.
Some info is given in these threads:
http://www.msfn.org/...n-its-clusters/
http://reboot.pro/to...-under-windows/
http://reboot.pro/to...-memory-drives/

And something only slightly related here:
http://reboot.pro/to...ectors-on-nt52/

As I see it, and BTW in this case it is just a "do not do things more complex than needed" approach, there is not much sense in aligning a FAT32 filesystem on an internal hard disk, the SATA bus largely exceeds the speed of the device, which (on modern disk drives) normally have a high speed on-board RAM cache, and FAT32 is not suitable (due to file size limits) as a "modern" generic storage filesystem, so my opinion is that the trouble involved does not has a good enough counter-value in speed increase that you can actually sense/measure.
It makes instead A LOT of sense on USB sticks and similar devices (CF cards, SD cards, etc.) because they are non-cached, inherently "slow" devices connected additionally to a slowish bus.


Wonko

[Wonko the Sane]

On a side note, after further tests the hiccup seems to be connected to another issue.
The backup bootsector that by definition is (or should be) the first sector OUTSIDE the filesystem/volume (but inside the partition) is managed all in all "correctly", when you access the logicaldrive (i.e. the "drive letter", i.e. "volume", i.e. "filesystem space") it is downright ignored.
This is - pardon me the pun - "logical".
 
The issue is with "Total sectors" in the filesystem (in the bootsector, offset 0x028).
The NTFS seems to be accessed as "clusters", then any amount for  "total sectors" that is not exactly divisible by cluster size will produce a "fractional end cluster".
This "fractional end cluster" which can be between 1 and 15 sectors depending on cluster size, is evidently NOT part of the volume, notwithstanding the fact that the sectors belonging to this "fractional end cluster" are listed within "total sectors".
In practice the quirk is within the FORMAT command.
Seemingly it tries to "fill up to the brim" the space (number of sectors) given by the partition table entry BUT it uses a "wrong" algorithm.
With these "definitions":
VSC=Volume Size in Clusters
CS=Cluster Size
TSPTE=Total Sectors from Partition Table Entry
TSBS=Total Sectors in BootSector
The used algorithms are evidently:

• VSC = INT((TSPTE-1)/CS)
• TSBS=TSPTE-1

 
While they should have been:

• VSC = INT((TSPTE-1)/CS)
• TSBS=VSC*CS

IF done correctly, this approach would have created a "no man's land" (NML) after the filesystem and before the backup bootsector of size variable between 1 and 7 whenever:
INT((TSPTE-1)/CS) is not equal to (TSPTE-1)/CS of size NML=MOD((TSPTE-1)/CS)
 
BUT "as is" it creates something that is NOT in the actual volume BUT within the Total sectors in the bootsector.
Still a No Man's Land, but a "camouflaged one".
 
 
This flawed behaviour allows us to define the position of the backup bootsector as "first sector after Total Sectors in the BootSector" but leaves us with this variable space between 0 and 15 (obviously the smaller volumes, where Cluster Size= 1 sector are not affected by this) that vanifies (unless corrections are made) the correct imaging (and restoring) of the logical drive on a hard disk.
 
Evidently, Clonedisk does not "trust" the "definition" that the OS makes of the LogicalDrive and counts (correctly) the sectors in TSBS.
The other mentioned utilities on the contrary do trust this "definition" resulting in the missing handful of sectors when there is a rest in the division.
 
The good news are that *somehow* we found a place where we can store some (small) piece of info that won't be touched during normal operation of the system (not entirely unllike the "hidden sectors" we may have after the MBR and before the PBR of first partition).
 
 
Given the synonym of No Man's Land:
http://www.thefreedi...nary.com/No Man's+Land
of Twilight Zone:
http://www.thefreedi...m/twilight zone
 

An area of ambiguity between two distinct states or conditions:

 
I vote for calling this area Twilight Zone or TZ for simplicity. 
So, given that:
MBR=MBR
HS= Hidden Sectors
NBBS=NTFS Backup Boot Sector
NTFS=NTFS Volume or Filesystem
we have just changed the layout (example with single primary partition) from:
MBR - (HS) - NTFS - NBBS
to:
MBR - (HS) - NTFS - (TZ) - NBBS
 
 

Wonko

[erwan.l]

Hi Wonko,

Checking a few threads here and there, i stumbled upon this (2 months old) post.

 

<quote>

Our friend erwan.l is seemingly (I hope momentarily) MIA  , but the thingy seems like working consistently   and should be in the same speed range as dsfo and dd for windows.

</quote>

 

Terribly busy with personal and professional stuff, i still enjoy reading you and the other guys.

I plan to go back on personal dev and contributing to the community thus.

happy to read some positive comments on clonedisk : a tool which I should definitely refresh and polish and make opensource.

 

<quote>

Evidently, Clonedisk does not "trust" the "definition" that the OS makes of the LogicalDrive and counts (correctly) the sectors in TSBS

</quote>

 

I indeed use datas from the BS : total_size:=total_sectors*PBootSequence^.wbytesPerSector;

 

Cheers,

Erwan

[Wonko the Sane]

Hi Wonko,

Checking a few threads here and there, i stumbled upon this (2 months old) post.

Happy to know you are still around from time to time .

 

Wonko