I'm about to use IFW Copy to duplicate my possibly failing 40GB laptop drive to another (hopefully healthy) 40GB drive (inlcluding my BOOTIT EMBR partition), and then move the new drive into my laptop. However, the specs on the drive are ever so slightly different. Here's the info from IFW:

Source drive:Size: 38154 MBDevice CHS: 1022/254/63

Target drive:Size: 38154 MBDevice CHS: 1023/254/63

Strangely, while the Windows XP's "Computer Management / Disk Management" util also says the source drive is 38154 MB, it says the target drive is "only" 38147 MB (weird, one more cylinder, but maybe 7 MB less space).

Given these differences (and especially since the target might be a tiny bit smaller), do I need to set either the "Scale to Fit" or "Aligned Copy" options? Each of the three partitions (not including the 8 MB EMBR partition) currently have at least 15% free space, so I'm not risking "overflowing" the target drive, but I can't figure out if these options (or other ones) are necessary when the disks are not 100% identical.

Okay, "Scale to Target" is pretty straightforward (and I guess can be used whether the target is larger or smaller than the source), but the documentation on "Scale to Fit" is a bit confusing. Could you explain it more clearly? Or at least tell me if there is a disadvantage (in the case I described) to just using the simpler to understand "Scale to Target"?

Scale to Fit will exclude any unallocated space located after the last partition on the source drive when determining the size of the drive. For example, if you had a 500GB drive with a 100GB partition on it followed by 400GB of unallocated space, copying this drive to a 1TB drive would result in a single partition filling the drive (100GB resized to 1TB). Scale to Target would expand the 100GB partition based on the size of the drive and you would end up with a 200GB partition and 800GB of unallocated space.

However, after 5 hours my copy "finished", but now I'm stumped. The disk copy says it completed, but I got the following screen:

Note that the copy is listed as completed (even the "Cancel" button is gone, and replaced with "Close"), yet it's showing only an 86% progress (and 43 minutes left to go). The end of the IFW.log file says:

I know about the bad sectors (I posted about them yesterday in another topic), so far they seem to be on a non-critical section of my C: drive (Windows is booting up and the computer is so far running fine), and the number of sectors hasn't increased since yesterday, but I'm trying to copy the drive before it becomes critical.

The other problem is that the target drive (connected via a USB to IDE cable) appears not to have been changed after the copy. After the copying finished, I safely removed the USB drive, shut down my computer, restarted the computer, reconnected the USB drive, and the target drive doesn't look like anything has happened to it. Here are some (hopefully) relevant screenshots:

From IFW:(I grayed out the name of my C: drive for privacy.)The source drive is HD 0, the target drive is HD 3. Note that there are no partitions on HD 3.

Some other screenshots (from Windows Disk Management)Source: Target:

Using Windows Disk Management util, I initialized HD 3 before starting the copy, but I did not partition it (I assumed IFW copy would do that).

Except as a last resort, I don't want to swap hard drives until I'm sure a bootable copy has been made. This is on a laptop, so swapping is a bit of a pain (though I've done it before), also this is my only computer connected to the net, so if the new drive doesn't work, I have to swap back to the old one to get more answers.

Any ideas why the copy supposedly completed successfully, yet the screen showed only 86%, and the target drive doesn't look like it was written to? BTW, I'm running XP Pro.

Does the log show anything for the other partitions? I don't see them in what you posted. It looks like it failed on the first partition (if the copy is aborted or canceled on the first copy there won't be any partitions on the destination drive). Does it make a difference if you use the Ignore IO Errors option?

Have you run chkdsk /r on the partition to see if the bad sectors can be marked out?

While testing, you could skip using the Wipe and Validate Byte-for-Byte options. It would save a lot of time.

TeraByte Support(PP) wrote:1) Does the log show anything for the other partitions? I don't see them in what you posted. It looks like it failed on the first partition (if the copy is aborted or canceled on the first copy there won't be any partitions on the destination drive). 2) Does it make a difference if you use the Ignore IO Errors option?

3) Have you run chkdsk /r on the partition to see if the bad sectors can be marked out?

4) While testing, you could skip using the Wipe and Validate Byte-for-Byte options. It would save a lot of time.

1) You're seeing the entire log (other than the edited hexdumps indicated in my post). The LogLevel is set to 10.

2) I intentionally did not ignore IO errors because I wanted to see them at the time they occurred (which only happened once, and I chose to continue, not abort). Also, the doc for IFW Copy says about the "Ignore IO Errors" (page 89):

Generally, you should select this option only if you need to copy to a target drive that contains known bad sectors. On some systems, if you select this setting and Image for Windows encounters bad sectors, there will be a significant delay as the internal retry/recovery routine of the drive attempts to handle the bad sector(s).

My target drive is new, hopefully there aren't any bad sectors (and the log didn't show any evidence of them).

The LBA failures happened at 1:53 and 2:39 (I'm assuming that this was when the bad spots were read and then verified). The backup continued for about 2.5 more hours until it "completed" at 5:06, with no further errors reported. Why would it continue with the copy if the previous bad sectors caused IFW to think it had failed? Also the error code was 0. Why would that happen if there were other problems?

3) I haven't done chkdsk/r because I've been trying to back things up before things fail, and I guessed that IFW Copy would have prompted me more if it couldn't properly finish the job. I may have to do that next.

4) Wiping doesn't take that much time (only about 15% of the space is free), but I guess if I use IFW again, I'll turn that off as well as Validate Byte-for-Byte, but I was trying to make sure I was getting the best copy possible.

I'm thinking I'll have to start using more manual methods to create partitions and copy the data. I'll need to read a lot more (I used to do imaging pretty often, but it's been awhile and I honestly was hoping it would be a bit more automatic).

The reason it didn't look like it finished is because the byte-for-byte
failed and it knows at that point it failed so it stops, since keep failed
backups enabled, it ignores the validate error (copy only - probably should
change it to at least report) so that it doesn't clear out the boot sector
making the copy unusable on purpose. But, why nothing would be changed on
the target doesn't make since, especially when you see it writing to that
drive, just disable validate-byte-for-byte since you know it will fail. (sfc
could be used to compare files that can be opened).

I've already allocated the target partitions to match the source ones, I ran chkdsk/r on my C drive - it found bad sectors in only one file (a .swf flash file used in Windows\help\ that I've never even knew was there!). I've turned off Byte for Byte validation and wipe, and I'm about to try one more time.

Copying my drives D & E should be trivial to accomplish, but when copying drive C (with Windows) and the partition after E (with BOOTIT EMBR) I want to make sure I get it right.

In reading the manual and some other posts, I read that "When you copy the boot partition use the "set active" and "copy first track" options. - Does this apply to the "new" drive C or to the new BOOTIT partition?