A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Windows 10 » Windows 10 Help Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

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



 
 
Thread Tools Rate Thread Display Modes
  #31  
Old January 21st 19, 01:07 AM posted to alt.comp.os.windows-10
Char Jackson
external usenet poster
 
Posts: 10,449
Default I cloned the partition and it's not the same size!!

On Sun, 20 Jan 2019 18:41:05 -0500, micky
wrote:

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?


You already have a few people tossing info into the ring, which can get
confusing, so I'm hesitant to blabber on. But if it were me, I'd use
Macrium Reflect again, this time being extra careful about each step, as
I'm sure you were the first time. I forgot or never knew whether you
were cloning a disk or only one or more partitions, so be sure in your
mind what you're trying to do.

I've never seen any clone tool fail like your first attempt did, so I'm
curious to see if you can replicate the weird results or if it just
works as expected the second time.

Ads
  #32  
Old January 21st 19, 01:37 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default I cloned the partition and it's not the same size!!

micky wrote:
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.


I'm still working on a test case here. Just to see
how much of a delta there is. The output format of the
tool I'm using, needs to be "cleaned up" with gawk
and a script. I need a nap first though, as I just
finished shoveling snow :-/ Paul is too cheap to buy
a snowblower.

Paul
  #33  
Old January 21st 19, 02:09 PM posted to alt.comp.os.windows-10
Frank Slootweg
external usenet poster
 
Posts: 1,226
Default I cloned the partition and it's not the same size!!

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.


It's very hard to follow this thread, so I might be wrong, but ...

Call me stupid, but a clone is a clone of the contents of the
partition(s) *at the time the clone was made/started*.

Comparing a clone of a partition with the (non-)original, *after the
fact*, is IMO an exercise in futility, especially for a system partition
(C, which is what we're talking about here AFAICT. In the meantime -
i.e. between the time the clone was made/started and the current time -
many, many files, probably thousands [1], will have been changed/added/
deleted.

Thoughts?

[1] Your run-of-the-mill C: partition easily contains hundreds of
thousands of files.
  #34  
Old January 21st 19, 04:03 PM posted to alt.comp.os.windows-10
Char Jackson
external usenet poster
 
Posts: 10,449
Default I cloned the partition and it's not the same size!!

On 21 Jan 2019 13:09:44 GMT, Frank Slootweg
wrote:

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.


It's very hard to follow this thread, so I might be wrong, but ...


I came in late and haven't made an effort to catch up, so you're
probably ahead of me. I can't even say for sure what the original goal
was, other than a clone operation apparently didn't give the expected
results.

Call me stupid, but a clone is a clone of the contents of the
partition(s) *at the time the clone was made/started*.

Comparing a clone of a partition with the (non-)original, *after the
fact*, is IMO an exercise in futility, especially for a system partition
(C, which is what we're talking about here AFAICT. In the meantime -
i.e. between the time the clone was made/started and the current time -
many, many files, probably thousands [1], will have been changed/added/
deleted.

Thoughts?


[1] Your run-of-the-mill C: partition easily contains hundreds of
thousands of files.


You're exactly right, so when trying to image/clone/backup a Windows
system drive, especially and specifically when the user expects to
compare the results to the original source with the expectation that
they will match, it's probably critical to do the operation from a
rescue media, NOT with the OS running. Once the OS is running, there
should be no expectation that things will match.[2]

As an experiment, he could boot his favorite image/clone tool from a
rescue media, then create two clones, one right after the other, without
booting into Windows in between. I'd expect the two clones to match each
other, but I wouldn't expect either of the two clones to match the
source drive after Windows has once again been booted.

[2] I think the current case is different or worse than what you and I
are discussing, though, since if I'm reading correctly the clone has far
more files than the source had, which might indicate that files that are
linked on the source were actually read/written twice to the clone. That
would be very odd, though, since Macrium is well aware of how to deal
with that situation. That's why I suggested he just do it again and see
if he gets the same weird result.

  #35  
Old January 21st 19, 07:19 PM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default I cloned the partition and it's not the same size!!

Char Jackson wrote:
..

I came in late and haven't made an effort to catch up, so you're
probably ahead of me. I can't even say for sure what the original goal
was, other than a clone operation apparently didn't give the expected
results.


I did a test here, cloning a running C: to another disk.
And it worked as expected. I turned on System Restore, put
a few loose files in the Recycle bin, had hibernation turned on.

pagefile copied
hiberfile copied
System Volume Information - may have been copied, but as soon as
it is mounted by the running system and
System Protection defaults to OFF for the
volume, the folder contents get removed.
This accounts for most of the size difference.
Recycle bin seemed to copy (there are files with names, in the appropriate area)

Since the OS never stops using files on C: and has a number
of them open while the backup is running, the dates and
sizes will be a tiny bit different on those. Functions
such as "Sleep Study" and other things that collect ETW,
the Search Indexer never leaves Windows.edb alone and
so on.

I'm satisfied, for the degree to which I can control
conditions, it's working properly.

Doing the clone offline, from the Macrium Rescue CD, should
give a tighter correlation. As there's no opportunity to
mess it up, before you then boot into Linux and measure it
again (the two of them). I suppose I should do a run
like that and have a look.

Paul
  #36  
Old January 21st 19, 09:20 PM posted to alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default I cloned the partition and it's not the same size!!

On 21/01/2019 00.40, micky wrote:
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?


They should, yes, but we are trying to guess what happened. :-)

Later I read another post that said some folders were protected (IIRC)
and did not display, but were copied, and then lost the protection, so
in the copy they display. Or something like that, I'm writing from memory.

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


But cloning software "should" reformat to match the original.


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.




--
Cheers, Carlos.
  #37  
Old January 22nd 19, 08:16 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default I cloned the partition and it's not the same size!!

micky wrote:
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.


I tried cloning using the CD, and that "solves" the
System Volume Information function. Macrium can clone the
contents of that successfully, at least using the rescue CD
to use it. The reason the clone you do from your regular
OS doesn't work quite as well, is because when the clone
mounts, Windows checks the "status" of System Protection
on the volume and it's supposed to be OFF, so SVI contents
are removed in response.

When you use the Rescue CD to clone, both SVI are the same.

*******

There was one weirdness when the clone was done.

It wants to write a log of the command used to clone, into the source C: .
This is so you could repeat the command some day - assuming somehow
you could figure out where this file is located.

ProgramData/Macrium/Reflect/962DC253AFA09105_Clone.html

Now, when the Rescue CD does the write to the source C: volume,
something strange happens. It selects a filenum which is
already in usage. The filenum is used to store a recycle bin
path. That gets bumped to a new filenum, as well as one
other file sitting in the recycle bin has its filenum
bumped.

In addition, when the "bootability" of the cloned volume is
fixed up by Macrium, it has to do a write to the SYSTEM hive.
So the SYSTEM file has a different date stamp than the source.
The size remains the same.

In totality, it isn't "forensically clean" - a forensics guy
would be mortified if this happened (process wouldn't stand up
in a court of law). (That's why those people would copy with "dd".)
But for most practical purposes, nothing even remotely important
changes when you clone using the CD. Just a weirdness with
the filenum for a couple items in the $MFT.

It's perfectly OK for filenums to be re-allocated when the
filenums are recycled. That's a normal part of how the $MFT
works. But the footprints in this case are downright weird,
because some "files at rest" are getting shuffled, and that
really shouldn't happen. It's more the lack of a logical
explanation, than "damage" as such.

The differences when cloning a running OS, are going to be
there because some internal processes of the OS never stop,
and they keep puking stuff into the file system. And that's
at least a couple hundred megabytes of crap by the time
you get around to shutting down the OS.

Large quantities of loss, come when the clone loses its
System Volume Information contents just as the cloned volume
is mounted by the running OS. If you were to boot the
clone, then check System Protection, there should be
no restore points in there, whereas the source OS
has restore points. But this behavior of the OS was
always a problem, and the "settings are wrong" whether
System Protection is enabled or System Protection is
disabled, on volumes other than the OS volume. It suggests
having System Protection on Data Volumes is a mistake.

What I'm seeing is explainable, with tiny exceptions :-)

Paul
 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 02:25 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.