Image for DOS shows incorrect MiB Processed/Remaining (copy)

[shahrukh]

I am doing a Copy from a SATA drive to an external USB drive (in a SATA enclosure). Both drives are identical 750 GB WD 7200 rpm drives.

The Copy works just fine but the statistics show a sum of MiB Processed + Remaining to be 1,078,377 MiB instead of the 715405 MiB that one would expect (and which is correctly shown as such in the earlier "Select Copy Location" screen as the total drive size), i.e., 50.7% more than the actual capacity.

This number 1,078,377 stays constant as the sum of the two displayed fields throughout the operation: at the start, middle and close to the end (the last digit of the sum oscillates between 6 and 7 owing to rounding).

I'm using the latest 2.93 version but I recall a similar behaviour in a much earlier version (from 2012) that I had originally purchased.

What gives???

[TeraByte Support]

You have both reading and writing that is counted in the
processed/remaining.

"shahrukh" wrote in message news:9193@public.image...

I am doing a Copy from a SATA drive to an external USB drive (in a SATA
enclosure). Both drives are identical 750 GB WD 7200 rpm drives.

The Copy works just fine but the statistics show a sum of MiB Processed +
Remaining to be 1,078,377 MiB instead of the 715405 MiB that one would
expect (and which is correctly shown as such in the earlier "Select Copy
Location" screen as the total drive size), i.e., 50.7% more than the actual
capacity.

This number 1,078,377 stays constant as the sum of the two displayed fields
throughout the operation: at the start, middle and close to the end (the
last digit of the sum oscillates between 6 and 7 owing to rounding).

I'm using the latest 2.93 version but I recall a similar behaviour in a much
earlier version (from 2012) that I had originally purchased.

What gives???

[shahrukh]

TeraByte Support wrote:
> You have both reading and writing that is counted in the
> processed/remaining.

OK, it wasn't intuitive that there'd be double counting in the case of a copy (where every read must be followed by a write) but the number now makes sense. Since only used space is counted and the disk is about 75% full, that's consistent with the "150% of actual size" that I was observing. Thanks for the explanation.

But while I'm on the subject ... what is the order of writing of files? Am I correct in assuming that it's a file-by-file copy (rather than sector-by-sector copy) with special handling for MFTs, MBRs and the like?

And if it's a file-by-file copy, are the files written in sequential sector order on the destination drive? So is there in essence an automatic defragmentation done at the same time?

[TeraByte Support]

it's not file by file.

"shahrukh" wrote in message news:9201@public.image...

TeraByte Support wrote:
> You have both reading and writing that is counted in the
> processed/remaining.

OK, it wasn't intuitive that there'd be double counting in the case of a
copy (where every read must be followed by a write) but the number now makes
sense. Since only used space is counted and the disk is about 75% full,
that's consistent with the "150% of actual size" that I was observing.
Thanks for the explanation.

But while I'm on the subject ... what is the order of writing of files? Am I
correct in assuming that it's a file-by-file copy (rather than
sector-by-sector copy) with special handling for MFTs, MBRs and the like?

And if it's a file-by-file copy, are the files written in sequential sector
order on the destination drive? So is there in essence an automatic
defragmentation done at the same time?