Errors when copying disks with IFW 2.71 in WinPE

[pjb926]

I am trying to create a copy script that can copy one disk to another and verify the copy byte-for-byte. I am using IFW 2.71 and WinPE 3.1 32-bit (Windows 7 plus SP1 AIK service pack). The problem I am seeing is that the copy seems to work correctly for the first 90%+, and then the time remaining and MiB remaining jump to unbelievably high numbers.

The CMD options I am using are:

For standard disks:
imagew.exe /copy /sd:w0 /td:w1 /rft /skp:0 /skh:0 /vb /dpc /rb=0 /dpwr /log:0

For encrypted disks (using the RAW option):
imagew.exe /copy /sd:w0 /td:w1 /raw /rft /skp:0 /skh:0 /vb /dpc /rb=0 /dpwr /log:0

The problem I am experiencing occurs whether or not the GUI is used, it is called from a command prompt, or though a script or batch file.

Any suggestions on what I might be able to do to get around this issue?

Thanks!

[celavey]

I am not sure what is the problem you get from there, but I am using a 64-bit OS and it worked for me perfectly. Don't you think the problem comes from this?

[TeraByte Support]

sounds like it's hitting bad sectors - you'll have to leave it sit to see if
they eventually get reported (once Windows returns with an error code).

"pjb926" wrote in message news:2304@public.image...

I am trying to create a copy script that can copy one disk to another and
verify the copy byte-for-byte. I am using IFW 2.71 and WinPE 3.1 32-bit
(Windows 7 plus SP1 AIK service pack). The problem I am seeing is that the
copy seems to work correctly for the first 90%+, and then the time remaining
and MiB remaining jump to unbelievably high numbers.

The CMD options I am using are:

For standard disks:
imagew.exe /copy /sd:w0 /td:w1 /rft /skp:0 /skh:0 /vb /dpc /rb=0 /dpwr
/log:0

For encrypted disks (using the RAW option):
imagew.exe /copy /sd:w0 /td:w1 /raw /rft /skp:0 /skh:0 /vb /dpc /rb=0 /dpwr
/log:0

The problem I am experiencing occurs whether or not the GUI is used, it is
called from a command prompt, or though a script or batch file.

Any suggestions on what I might be able to do to get around this issue?

Thanks!

[pjb926]

I tested a couple of drives, and the checksums matched for them, so it looks like the copy is working fine.

I tested with an older version (2.62a I think) and it took about the same amount of total time to run, but did not have the ballooning estimate error at the end of the process.

Both versions ended up with correct checksums after the copy, but the older version will not run from command line for encrypted disks due to an error "Access violation." calling IFW and using the GUI manually works fine. Non-encrypted disks copy fine in all scenarios when not using the /raw option on the older version.


Can I provide additional details to help with this issue? In the meantime, I am going to move forward (cautiously) with using the newer version so I can script the copies and ignore the time estimate.

[TeraByte Support]

Just use 2.71. If your hard drive has relocated the sectors then it should
work out ok.

"pjb926" wrote in message news:2327@public.image...

I tested a couple of drives, and the checksums matched for them, so it looks
like the copy is working fine.

I tested with an older version (2.62a I think) and it took about the same
amount of total time to run, but did not have the ballooning estimate error
at the end of the process.

Both versions ended up with correct checksums after the copy, but the older
version will not run from command line for encrypted disks due to an error
"Access violation." calling IFW and using the GUI manually works fine.
Non-encrypted disks copy fine in all scenarios when not using the /raw
option on the older version.


Can I provide additional details to help with this issue? In the meantime,
I am going to move forward (cautiously) with using the newer version so I
can script the copies and ignore the time estimate.

[pjb926]

Could be. I am using WinPE 32-bit because I need to support some older HW. I will try 64-bit if I get a chance and see if it works. I will need to redo all my drivers first since the last 64-bit I made didn't work at all.

celavey wrote:
> I am not sure what is the problem you get from there, but I am using a
> 64-bit OS and it worked for me perfectly. Don't you think the problem comes
> from this?