I cloned the partition and it's not the same size!!

In alt.comp.os.windows-10, on Sat, 19 Jan 2019 19:38:48 +0100, "Carlos
E.R." wrote:

On 19/01/2019 18.14, Paul wrote:
Carlos E.R. wrote:
On 19/01/2019 08.48, Paul wrote:
You would expect a clone though, to be "identical",
so whatever sizing command you use, should make the
same mistakes on both volumes.

I was expecting /some/ differences if the cluster size was different,
simply because of the lost space at last cluster of each file. But I did
not expect differences in the file list that "tree" displays, they
should be identical in a clone.

But I'm not familiar with the tool used (I use clonezilla).


There are around twenty different free/trial backup/cloning
tools that use shadow copies. And for the most part,
they arrange clones by doing cluster level copying.
And when copying clusters, they generally don't mess around
and are trying to "verbatim" copy the clusters. A good tool
just makes a cluster list and copies it in linear cluster order.

If you ask a tool to resize the partition when cloning it,
the software switches copy strategy (seems to be more file-oriented,
because the output disk is "mostly defragmented"). But the
size of the clusters is still maintained. Even if shrinking
a 1TB partition to a 32GB partition, the same cluster
size would be used (assumes actual data content is less
than 32GB in size).

The reason for using VSS shadow copies, is it's possible to
backup or clone even an OS drive, without stopping. No need
to shutdown and reboot into a maintenance OS, to copy the
OS partition. This makes the usage of VSS a rather
popular feature.

For a person who is paranoid about corner cases or something,
the backup/clone tools also generally support offline copying
with their own boot media (CD).

Changing cluster sizes on a partition, you would think that
would be dead easy. I bought a commercial tool where that
was a feature, and it damaged files when I tested it. So
don't "trust" software to perform such a function, and
test thoroughly that it actually works.

It can be done if what it does actually is to copy files on a newly
formatted partition. But you are right, an image type of clone doesn't
do that.

btw, the destination was a brand new hdd to which I had copied one file
(probably to verify that the drive worked) which I then deleted.

In alt.comp.os.windows-10, on Sat, 19 Jan 2019 14:45:25 +0100, "Carlos
E.R." wrote:

On 19/01/2019 07.43, micky wrote:
In alt.comp.os.windows-10, on Fri, 18 Jan 2019 17:50:58 -0500, Paul
wrote:

......



Well, I ran the DOS Tree command for both partitions and though I
haven't run the results through a compare program yet, I see that the
tree is about 3,300,000 bytes for the source partition, and 4,200,000
for the destination partition.

Count the lines instead.

Okay. Source is 44,268 Destination is 64,522. That's a big
difference! A lot bigger by percentage than the 8 missing GB out of
194.

Darn. I should really pursue this. But it's a very busy time for me.

BTW, the last pages of the each tree file, at the ends, are identical.


(I mentioned the 4th partition that I cloned and that is almost all of
my data**, so even if the clone is not good, I have 99% of my data.)

** There are a couple things that are stored someone else that I haven't
backed up. I should try to remember what they are. So far the only
one I know for sure is the script I wrote to make Autohotkey work.
Okay, let me copy that to the Data directory... I can't find it! I was
sure if I right clicked on the icon there was a line to edit it, but
there isn't. And it's not in the Autohotkey directory either. Very
strange. Because I hadn't copied this file to the laptop and couldn't
figure out how to write it a second time, I had to pay for Keyremapper
when I was away from home.


Quite a big differerence. And the destination tree is bigger, even
though the destination partition has 8GB fewer in use. Very strange,
if you ask me.

My clone doesn't have to be exactly the same if it will still boot from
it and run like the original. But because you can't boot win10 from a
USB drive, it's too much trouble to check if it really boots.

I'm not sure I used best options for the command -- haven't loooked up
what they all are yet -- but if it's a clone, the numbers should still
be the same, it seems to me.

Try ignore the 3 A's, each with a different diacritical mark, that start
each line!

I also looked at the trees adn the old one starts

C:\
ÃÄÄBat
³ ÀÄÄLogs
ÃÄÄboot
³ ÀÄÄmacrium
³ ÃÄÄDrivers
³ ³ ÃÄÄDisk
³ ³ ÃÄÄNetwork
³ ³ ÀÄÄUSB
³ ÀÄÄWA10KFiles
³ ÃÄÄfwfiles
³ ÃÄÄmedia
³ ³ ÃÄÄBoot
³ ³ ³ ÀÄÄFonts
³ ³ ÃÄÄDrivers
³ ³ ³ ÃÄÄDisk
³ ³ ³ ÃÄÄNetwork
³ ³ ³ ÀÄÄUSB

while the new one starts

C:\
ÃÄÄ$AV_AVG
³ ÀÄÄ$VAULT
ÃÄÄ$Recycle.Bin
³ ÃÄÄS-1-5-18
³ ÀÄÄS-1-5-21-3746805023-800245718-3893543110-1000
³ ÃÄÄ$R1UU8RT
³ ÃÄÄ$R6SJVNR
³ ÃÄÄ$RATAYMO
³ ÃÄÄ$RC79V99
³ ÃÄÄ$RDPGY3M
³ ÀÄÄ$RZRUJ97
ÃÄÄBat
³ ÀÄÄLogs
ÃÄÄboot -- they start looking the same at this line. But
there are extra lines in the destination which
should make it bigger instead of smaller.
³ ÀÄÄmacrium
³ ÃÄÄDrivers
³ ³ ÃÄÄDisk
³ ³ ÃÄÄNetwork
³ ³ ÀÄÄUSB
³ ÀÄÄWA10KFiles
³ ÃÄÄfwfiles
³ ÃÄÄmedia
³ ³ ÃÄÄBoot
³ ³ ³ ÀÄÄFonts
³ ³ ÃÄÄDrivers
³ ³ ³ ÃÄÄDisk
³ ³ ³ ÃÄÄNetwork
³ ³ ³ ÀÄÄUSB

I haven't looked at the end of each file yet.



That's strange for a clone.

In alt.comp.os.windows-10, on Sat, 19 Jan 2019 14:24:07 GMT,
wrote:

IIRC some cloning software will not transfer the pagefile and hibernate
files since they will be recreated.

That makes sense. I'll look into that.

hiberfl is 6.3 gigs. This is related to the amount of RAM I have,
right? And the percentage of RAM being used the last time one
hibernated. Since I have 8Gigs, 6.3 is reasonable.

pagefile is 20 gigs, at the moment. I'm only missing 8 gigs but maybe
it was smaller before.

So what does the clone have? 6.3 and 20+. Both files are there and, I
checked,exactly the same size.

Well, it was a good idea.


XXClone is one program, not really available anymore because the author
died without making arrangements, that doesn't copy those two files.

XXCopy, its sister program, is still available, because the old version
never expires. Actually XXCopy is what I used to copy the 4th
partition. I only copied data, no hiberfil or pagefil, but it woudl
have copied those too. It makes no exceptions and indeed the dest was
the same size as the source. (If you use the right parameter, It will
also copy the directory creation dates to be the same as the original,
which Xcopy and copy and some other programs don't do.)





Of course neither of these files is a directory, so this has notthing to
do with the tree file for the destination being 30% bigger and having
about 30% more lines.

On 19/01/2019 21.45, micky wrote:
In alt.comp.os.windows-10, on Sat, 19 Jan 2019 14:45:25 +0100, "Carlos E.R." wrote:
On 19/01/2019 07.43, micky wrote:
In alt.comp.os.windows-10, on Fri, 18 Jan 2019 17:50:58 -0500, Paul wrote:

......



Well, I ran the DOS Tree command for both partitions and though I
haven't run the results through a compare program yet, I see that the
tree is about 3,300,000 bytes for the source partition, and 4,200,000
for the destination partition.

Count the lines instead.

Okay. Source is 44,268 Destination is 64,522. That's a big
difference! A lot bigger by percentage than the 8 missing GB out of
194.

Huge.


Darn. I should really pursue this. But it's a very busy time for me.

BTW, the last pages of the each tree file, at the ends, are identical.

Well, that clone can't be right, the number of files is very different.
I would compare directory by directory. First create a list of
directories with their sizes and/or the number of files on each, but I
don't know how to do that in Windows. Then I would compare directories
with different sizes, to find out what is different.

--
Cheers, Carlos.

micky wrote:


Okay. Source is 44,268 Destination is 64,522. That's a big
difference! A lot bigger by percentage than the 8 missing GB out of
194.

You need to put on your "big forensic hat".

If you Robocopied C: to D:, I could easily see how this
would happen. WinSXS is hard linked to System32. There
are a number of files which are selectively linked to
System32. The scheme is part of Windows Update maintenance
of your OS. Hard linking means, even though the "measured
size" of WinSXS is 6GB, since only file pointers are used
to manage the pointer duplication, it only takes 500MB of
pointers to cause thousands and thousands of apparent copies.
Hard linking both saves space, but more importantly, it's
a part of making the update process work properly.

filenum 1234
pointer X (to WinSXS file)
pointer Y (to System32 file)
LBA 2344-2352 (a single 4KB cluster datafill)

If you Robocopy that file to D: , it looks like this.
As Robocopy "descends" the file tree, it runs into both
instances of filenum 1234 and dumbly copies the file *twice*.
Robocopy is not Macrium, and doesn't give a flying ****
what it's copying. It's natural for this to be the outcome.
Robocopy is no more clever than MSDOS "copy" is, in this
regard. And Windows has had a personality conflict with
regard to this file feature, since practically nothing
at user level deals with these situations properly.

filenum 1234
pointer X (to WinSXS file)
LBA 2344-2352 (a single 4KB cluster datafill)

filenum 230435
pointer Y (to System32 file)
LBA 123744-123752 (a single 4KB cluster datafill)

Now there are thousands of extra files, and thousands
of extra LBAs burned up on the destination drive.

Macrium should not do that. The Macrium D: would be:

filenum 1234
pointer X (to WinSXS file)
pointer Y (to System32 file)
LBA 2344-2352 (a single 4KB cluster datafill)

Only NFI.exe can help you with this aspect. And NFI
(written in the year 2000 or so), does not print on
the screen what "pointer X" and "pointer Y" are. You're
left to guess.

However, from Linux, the "inode number"
listed for a file from "ls -i" tells you which two
files are actually "sharing" information. There is
a refcount number ("2") which indicates two pointers
are present, and the "inode number", like on the
source drive. The refcount doesn't seem to be entirely
reliable on the Linux side, but the inode number is
good quality info. It gives the information that
NFI.exe should have printed in the first place. The
source drive would show like this.

inode 1234 refcount 2 WinSXS/somefile.dll
inode 1234 refcount 2 System32/someotherfilename.dll

There's not even a requirement that the filenames be
the same, when they're pointers like that.

One reason I have a hard time helping people with
these issues, it's because each utility only does
"half a job", and I have to use a collection of
bailing wire and binder twine. And nobody I help,
really appreciates doing a lot of extra work and
wasting their time, digging up the lists, correlating,
and figuring this stuff out. It's not hard, but
like everything on Windows, it's time consuming.

And while this particular issue is easy, I'm personally
"stumped" on permissions, and have no grasp of them
at all. I'm still in kindergarten. I've had a metric
ton of permission issues I couldn't fix (stuff I
suspect uses inheritance, but I was unable to track
down, and it didn't seem to be MIC either). And the
utilities and methods offered for permissions,
as just as poor as the ones to assess this issue.
Every utility I run into "assumes you know this
stuff", and don't need bootstrapping.

HTH,
Paul

On Sat, 19 Jan 2019 16:39:14 -0500, Paul wrote:

micky wrote:


Okay. Source is 44,268 Destination is 64,522. That's a big
difference! A lot bigger by percentage than the 8 missing GB out of
194.

You need to put on your "big forensic hat".

If you Robocopied C: to D:, I could easily see how this
would happen. WinSXS is hard linked to System32. There
are a number of files which are selectively linked to
System32. The scheme is part of Windows Update maintenance
of your OS. Hard linking means, even though the "measured
size" of WinSXS is 6GB, since only file pointers are used
to manage the pointer duplication, it only takes 500MB of
pointers to cause thousands and thousands of apparent copies.
Hard linking both saves space, but more importantly, it's
a part of making the update process work properly.

filenum 1234
pointer X (to WinSXS file)
pointer Y (to System32 file)
LBA 2344-2352 (a single 4KB cluster datafill)

If you Robocopy that file to D: , it looks like this.
As Robocopy "descends" the file tree, it runs into both
instances of filenum 1234 and dumbly copies the file *twice*.
Robocopy is not Macrium, and doesn't give a flying ****
what it's copying. It's natural for this to be the outcome.
Robocopy is no more clever than MSDOS "copy" is, in this
regard. And Windows has had a personality conflict with
regard to this file feature, since practically nothing
at user level deals with these situations properly.

That's why it's incorrect and misleading to call the result a clone.
Robocopy isn't able to properly clone a system drive.

If the OP intends to clone a Windows system drive, he should probably
use a tool that's been designed for that purpose. I'd use Macrium
Reflect Free, but there are many others.

Carlos E.R. wrote:


Well, that clone can't be right, the number of files is very different.
I would compare directory by directory. First create a list of
directories with their sizes and/or the number of files on each, but I
don't know how to do that in Windows. Then I would compare directories
with different sizes, to find out what is different.

Windows is one big land mine.

Forensics is a lot of work, and takes a good
deal of care to do right.

Out of the box, the single and only accurate accounting
of space in Windows, is when you do Properties on C: and
the "pie chart" or "used circle" comes up on the screen.
That one, is accurate.

Everything else the machine prints out, is *wrong*.

For example, I had a folder with a Junction Point in it,
where doing Properties on the folder says "3GB" and
doing Properties like a bank accountant would,
says "76GB". That's how bad it is. We're not talking
about small errors here - we're talking "gross" errors.

This is why, when you're in CleanMgr.exe and it offers
to delete a 3GB Downloads folder, it's actually going
to delete 76GB of stuff. Because it doesn't know any better.

The GUI was never updated to properly account
for file system features. Only the Properties dialog,
and only for the top level of partitions, can you be
assured the answer is correct.

*******

The above only applies to the C: partition.

For data partitions, so few file system features are
used, the accounting is perfectly normal there. And
you are unlikely to get any Bozo the Clown numbers.
Similarly, if you were looking at a Win98 C: drive,
things there would be normal.

The OS partition on the other hand, like a Win10 C:
partition, brings out the worst behaviors on size info.

Paul

In alt.comp.os.windows-10, on Sat, 19 Jan 2019 16:01:12 -0600, Char
Jackson wrote:

On Sat, 19 Jan 2019 16:39:14 -0500, Paul wrote:

micky wrote:


Okay. Source is 44,268 Destination is 64,522. That's a big
difference! A lot bigger by percentage than the 8 missing GB out of
194.

You need to put on your "big forensic hat".

If you Robocopied C: to D:, I could easily see how this
would happen. WinSXS is hard linked to System32. There
are a number of files which are selectively linked to
System32. The scheme is part of Windows Update maintenance
of your OS. Hard linking means, even though the "measured
size" of WinSXS is 6GB, since only file pointers are used
to manage the pointer duplication, it only takes 500MB of
pointers to cause thousands and thousands of apparent copies.
Hard linking both saves space, but more importantly, it's
a part of making the update process work properly.

filenum 1234
pointer X (to WinSXS file)
pointer Y (to System32 file)
LBA 2344-2352 (a single 4KB cluster datafill)

If you Robocopy that file to D: , it looks like this.
As Robocopy "descends" the file tree, it runs into both
instances of filenum 1234 and dumbly copies the file *twice*.
Robocopy is not Macrium, and doesn't give a flying ****
what it's copying. It's natural for this to be the outcome.
Robocopy is no more clever than MSDOS "copy" is, in this
regard. And Windows has had a personality conflict with
regard to this file feature, since practically nothing
at user level deals with these situations properly.

That's why it's incorrect and misleading to call the result a clone.
Robocopy isn't able to properly clone a system drive.

If the OP intends to clone a Windows system drive, he should probably
use a tool that's been designed for that purpose. I'd use Macrium
Reflect Free, but there are many others.

That's what I used.

Mentioned it in the first post, not that I expect everyone to read every
post.

I'm not surprised you have the impression, I think, that I used
Robocopyl

In alt.comp.os.windows-10, on Sat, 19 Jan 2019 22:27:10 +0100, "Carlos
E.R." wrote:

On 19/01/2019 21.45, micky wrote:
In alt.comp.os.windows-10, on Sat, 19 Jan 2019 14:45:25 +0100, "Carlos E.R." wrote:
On 19/01/2019 07.43, micky wrote:
In alt.comp.os.windows-10, on Fri, 18 Jan 2019 17:50:58 -0500, Paul wrote:

......



Well, I ran the DOS Tree command for both partitions and though I
haven't run the results through a compare program yet, I see that the
tree is about 3,300,000 bytes for the source partition, and 4,200,000
for the destination partition.

Count the lines instead.

Okay. Source is 44,268 Destination is 64,522. That's a big
difference! A lot bigger by percentage than the 8 missing GB out of
194.

Huge.


Darn. I should really pursue this. But it's a very busy time for me.

BTW, the last pages of the each tree file, at the ends, are identical.

Well, that clone can't be right, the number of files is very different.
I would compare directory by directory. First create a list of
directories with their sizes and/or the number of files on each, but I
don't know how to do that in Windows.

Neither do I.

Then I would compare directories
with different sizes, to find out what is different.

On the theory that some whole directories are missing -- and that must
be true because the trees are so different -- I was going to just
compare the trees. I dl'd wincmp and ran that.

Source Missing but found in Destination:
Windows Sidebar, which has a lot of subdirs. 46x~50=2300 lines
Configuration of Windows power shell, 1 line
ProgramData 46x~30 = 1380 lines
Recovery/SVI 3 lines
Users 46x33=1518 lines plus some others that follow soon after, 3 and
4 at a time
MyPersona/Appdata 46x234 = 10,700

plus a bunch of short stretches, 2 or 3 or 8 or 10.

You get the idea. I guess this are all files I can't see on my Windows
drive, but I can on the clone because they are not protected there.
Right?

This accounts for why the number of bytes in the destination tree is
greater, and why the number of lines in the destination tree is greater,
but not why the number of bytes in the whole partition is 8GB less!!

Wincmp gives some other information but I don't know how to interpret it
yet.

In alt.comp.os.windows-10, on Sat, 19 Jan 2019 19:49:01 -0500, micky
wrote:


On the theory that some whole directories are missing -- and that must
be true because the trees are so different -- I was going to just
compare the trees. I dl'd wincmp and ran that.

Source Missing but found in Destination:

Looked further: There are a couple lines that are idiosyncratic, but
there no lines missing from Destination that are found in the source.

And the program which apparently is free has a lot of good features,
including the ability to find moved pieces of text and a bar at the left
which marks in green or red where lines are found in one file but not
the other, and you can click on the bar, on a colored part for example,
and go straight there. Plus more.

Windows Sidebar, which has a lot of subdirs. 46x~50=2300 lines
Configuration of Windows power shell, 1 line
ProgramData 46x~30 = 1380 lines
Recovery/SVI 3 lines
Users 46x33=1518 lines plus some others that follow soon after, 3 and
4 at a time
MyPersona/Appdata 46x234 = 10,700

plus a bunch of short stretches, 2 or 3 or 8 or 10.

You get the idea. I guess this are all files I can't see on my Windows
drive, but I can on the clone because they are not protected there.
Right?

This accounts for why the number of bytes in the destination tree is
greater, and why the number of lines in the destination tree is greater,
but not why the number of bytes in the whole partition is 8GB less!!

Wincmp gives some other information but I don't know how to interpret it
yet.

On 19/01/2019 23.01, Char Jackson wrote:
On Sat, 19 Jan 2019 16:39:14 -0500, Paul wrote:

micky wrote:

....

That's why it's incorrect and misleading to call the result a clone.
Robocopy isn't able to properly clone a system drive.

If the OP intends to clone a Windows system drive, he should probably
use a tool that's been designed for that purpose. I'd use Macrium
Reflect Free, but there are many others.


He said on the first post:

I'm using Macrium Reflect Free to clone (not image) my internal hdd. It
has 4 partitions, two tiny and two big.

--
Cheers, Carlos.

On Sun, 20 Jan 2019 04:16:44 +0100, "Carlos E.R."
wrote:

On 19/01/2019 23.01, Char Jackson wrote:
On Sat, 19 Jan 2019 16:39:14 -0500, Paul wrote:

micky wrote:

...

That's why it's incorrect and misleading to call the result a clone.
Robocopy isn't able to properly clone a system drive.

If the OP intends to clone a Windows system drive, he should probably
use a tool that's been designed for that purpose. I'd use Macrium
Reflect Free, but there are many others.


He said on the first post:

I'm using Macrium Reflect Free to clone (not image) my internal hdd. It
has 4 partitions, two tiny and two big.

Thanks, Carlos. The OP brought that to my attention yesterday.

I'd be curious if Macrium Reflect could be enticed to create a second
abnormal "clone" or if this was a one-time anomaly. Of all of the times
that I've used it and all of the times that others here have used it, I
don't remember another report of the clone function not working as
expected, except for a couple of clear user-error cases, which I don't
think is the case here.

So rather than trying to examine and fix it, I would probably just start
over and do it again.

In alt.comp.os.windows-10, on Sat, 19 Jan 2019 19:49:01 -0500, micky
wrote:

Okay. Source is 44,268 Destination is 64,522. That's a big
difference! A lot bigger by percentage than the 8 missing GB out of
194.

Huge.


Darn. I should really pursue this. But it's a very busy time for me.

BTW, the last pages of the each tree file, at the ends, are identical.

Well, that clone can't be right, the number of files is very different.
I would compare directory by directory. First create a list of
directories with their sizes and/or the number of files on each, but I
don't know how to do that in Windows.

Neither do I.

Then I would compare directories
with different sizes, to find out what is different.

On the theory that some whole directories are missing -- and that must
be true because the trees are so different -- I was going to just
compare the trees. I dl'd wincmp and ran that.

Source Missing but found in Destination:
Windows Sidebar, which has a lot of subdirs. 46x~50=2300 lines
Configuration of Windows power shell, 1 line
ProgramData 46x~30 = 1380 lines
Recovery/SVI 3 lines
Users 46x33=1518 lines plus some others that follow soon after, 3 and
4 at a time
MyPersona/Appdata 46x234 = 10,700

plus a bunch of short stretches, 2 or 3 or 8 or 10.

You get the idea. I guess this are all files I can't see on my Windows
drive, but I can on the clone because they are not protected there.
Right?

This accounts for why the number of bytes in the destination tree is
greater, and why the number of lines in the destination tree is greater,
but not why the number of bytes in the whole partition is 8GB less!!

Wincmp gives some other information but I don't know how to interpret it
yet.

Did you see this list of lines from the tree that were missing from the
source but present in the destination. No comments on it.

In alt.comp.os.windows-10, on Fri, 18 Jan 2019 22:33:21 +0100, "Carlos
E.R." wrote:

On 18/01/2019 20.05, micky wrote:
In alt.comp.os.windows-10, on Fri, 18 Jan 2019 10:51:41 +0100, "Carlos
E.R." wrote:

On 18/01/2019 08.33, micky wrote:
Win 10 64 bits, Pro iirc.

I'm using Macrium Reflect Free to clone (not image) my internal hdd. It
has 4 partitions, two tiny and two big.

The two tiny ones seem okay and it's still working on the fourth
partition but the second partition, my boot partition is 194.15GB but
its clone is 186.29GB. On second thought, how can that be a clone?

Do both disks use the same sector size?

I'll check. The source was a 1.5T and destination 1T, both Western
Digital. Where do you find sector size?

https://stackoverflow.com/questions/9465451/how-can-i-determine-the-sector-size-in-windows

1 Run msinfo32 in command line that should popup a GUI window called
"System Information"
2 In the left pane select "System
Summary-Components-Storage-Disks". This should load info of all
drives in the right pane.
3 Find your desired drive and check the value for "Bytes/Sector". it
should say "Bytes/Sector 4096"

(but it may say 512)

But even if they're different, the 4th partition finished and that copy
was from a 200GB partition and the source had 108.01GB used and the
destination had the exact same number. So if sector size was the cause
for the 2nd partition, how come not the 4th

Ah, then I think it will not be the hard disk sector size, but the
cluster size after formatting the disk.

Both HDD's were 512.

I haven't had time to compare cluster size if they followed the rules
for 1.5T and 1 T wouldnt' they be the same?

I think these new WD drives came formatted and I didn't redo it.

Google "how to find cluster size in windows". The answer depends on what
format type you use.

Obviously then "Macrium Reflect" doesn't exact clone, but adapts
depending on the circumstances.

In alt.comp.os.windows-10, on Sun, 20 Jan 2019 16:16:13 -0600, Char
Jackson wrote:

On Sun, 20 Jan 2019 04:16:44 +0100, "Carlos E.R."
wrote:

On 19/01/2019 23.01, Char Jackson wrote:
On Sat, 19 Jan 2019 16:39:14 -0500, Paul wrote:

micky wrote:

...

That's why it's incorrect and misleading to call the result a clone.
Robocopy isn't able to properly clone a system drive.

If the OP intends to clone a Windows system drive, he should probably
use a tool that's been designed for that purpose. I'd use Macrium
Reflect Free, but there are many others.


He said on the first post:

I'm using Macrium Reflect Free to clone (not image) my internal hdd. It
has 4 partitions, two tiny and two big.

Thanks, Carlos. The OP brought that to my attention yesterday.

I'd be curious if Macrium Reflect could be enticed to create a second
abnormal "clone" or if this was a one-time anomaly. Of all of the times
that I've used it and all of the times that others here have used it, I
don't remember another report of the clone function not working as
expected, except for a couple of clear user-error cases, which I don't
think is the case here.

So rather than trying to examine and fix it, I would probably just start
over and do it again.

I have another identical HDD I could use. Should I use Macrium again
or do you recommend something else this time?