Anna wrote:
"Richie Hardwick" wrote in message
It's interesting that she's not replied to any of this.


"Daave" wrote in message
...
She will. :-)


Daave, Wally, Richie, et al...
And so I am...

And humbly too.

I was apparently mistaken re my last post to "Daave" re the cloning of a
source HDD containing multiple partitions - in Daave's example, three
partitions. I used as an example that the C: partition was 50 GB, a second
D: partition of 125 GB, and a third E: partition of 75 GB. The example
assumed a 500 GB external HDD was to be used as the destination drive and
had been set up with two partitions of 200 GB and 300 GB. The 200 GB
partition was destined to be the recipient of the contents of the source
HDD; presumably the 300 GB partition contained user data.

I stated (mistakenly) that one could clone the entire contents of the
source
HDD to *one* of the two partitions on the destination drive (in the
example,
the 200 GB partition) and the Casper 5 program would proportionally
allocate
disk-space for each of those source drive's three partitions on that
single
200 GB partition of the destination drive. So that the former 200 GB
partition on the destination HDD would, in effect, be split up
(proportionally) with three separate partitions mirroring the source HDD's
partitions. Mistakenly, and this is the important part, I indicated that
the
second 300 GB partition presumably containing user data would remain
untouched.

The information I provided was wrong. While it is indeed possible for the
user to easily clone the contents of the source drive's three partitions
(in
our example) to the destination HDD and, using the Casper program, set up
the size of each of those three partitions on the destination drive, any
remaining disk space would be considered "unallocated". That second
partition (in our example) that previously existed on the destination HDD
would disappear (along with its data, of course!) and become part of the
"unallocated" disk space. Richie correctly pointed out my mistake in this
regard.

My only excuse (as flimsy as it might be!) is that the scenario I
described
*did* exist at one time in the Casper program. I can't recall whether it
was
part of the predecessor Casper 4 program or, more likely, a beta version
of
one of the Casper versions I worked with in the past. It might even have
existed in an earlier "build" of Casper 5. I just can't remember. But in
any
event that capability I described does not exist in the Casper 5 program.
Obviously I hadn't used the current 5 version in the manner I had
described.
I should have tested it out to make certain the info I was providing was
correct, but I didn't.

So my apologies to all of you for the misinformation.

In any event, here's (I hope & trust!) the *real* story...

In the example given above involving a source HDD with three partitions,
the
user would have the following options re cloning the contents of that
source
HDD (the three partitions) to the destination drive, a 500 GB HDD...

1. He or she could allow the Casper program to proportionally create the
three partitions on the 500 GB destination drive (466 GB binary). So that
in
the example given the first partition on the destination HDD would be
(approx) 102 GB, the second partition 248 GB, and the third partition 116
GB. So that the entire disk space of the destination drive would be used
to
hold the contents of the source disk.(Again, all figures approximate); or,

2. The user could perform a disk-to-disk clone in which case the three
partitions created on the destination drive would mirror the disk-space of
each of the three source drive's partitions (and of course, contain their
contents). The remaining disk space would be unallocated.

3. The user could specify how the disk space is to be allotted, in effect
resizing the three destination drive partitions to whatever size he or she
desires, naturally assuming the individual partition size would be
sufficient to contain the contents of the source drive's partition. Again,
the remaining disk space would be unallocated.

Again, my apologies to all for the misinformation I previously provided
and
for any inconvenience it may have caused anyone.
Anna

OK, thanks Anna, and that at least clarifies something for me. I know we
(or some of us) have been discussing this a long time, but there really is a
lot to it, when you get into it, in detail, and try to be completely
accurate.

I guess the bottom line is this then: if you use Casper for cloning and
backup purposes, you can NOT have any other partition data on the
destination drive (as it will be removed). Now THAT is a serious
consideration, and gives one main advantage to using imaging, as you can
store as many image backups on the destination drive (AND other partitions
with data) as you want. But for simple backup purposes, and for many
users, it might be fine, and is probably simpler. I liked all the options
offered by ATI better, however, but many users might be put off by that, as
you've suggested.

Boot-It-NG (or PM), OTOH, makes (or can make) partition-to-partition copies
AND lets you preserve the other partitions, if there is enough space.

However, in order to make a so called partition to partition copy, the
destination partition area of the drive needs to be first deleted (i.e,
marked as unallocated space), and only THEN you you copy the partition over
to the destination drive (in that freed space). It is a true partition
copy, and NOT an image or single file. I'd call it a "cloned partition".
And it is an EXACT replica of what was on the source drive (no compression).