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