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

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?

And isn't 8GB a lot to be missing? Has anyone found any lost GB?

Maybe I should wait until the whole thing finishes and see if there is a
report with error messages and explanations, but I've used the program
before and I don't remember any report, and I'd sort of expect error
messages to be in real time so if they're important the user can stop
wasting time, etc. running the program.



Also, the first partition, a tiny one, is only 99MB and only 32.16MB are
used. It's listed as the active, system partition. I bought the
computer used from a computer shop and this is the way it was set up. If
I started with a bare drive and installed win10 myself, would that 99MB
partition be there? Does it serve some special purpose?

Does it have something to do with multi-booting different OSes?

I think this computer was originally winVista and then win7 and finally
win10 -- you can see where someone scratched off the OS name from the
decorative, stamp-sized windows plate on the front -- but since the HDD
is 1.5TB, T B, I figure the shop replaced the HDD and actually did
install win10 from scratch. You couldnt' get a 1.5TB drive in winV or
7, could you?

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?

And isn't 8GB a lot to be missing? Has anyone found any lost GB?

Maybe I should wait until the whole thing finishes and see if there is a
report with error messages and explanations, but I've used the program
before and I don't remember any report, and I'd sort of expect error
messages to be in real time so if they're important the user can stop
wasting time, etc. running the program.



Also, the first partition, a tiny one, is only 99MB and only 32.16MB are
used. It's listed as the active, system partition. I bought the
computer used from a computer shop and this is the way it was set up. If
I started with a bare drive and installed win10 myself, would that 99MB
partition be there? Does it serve some special purpose?

Does it have something to do with multi-booting different OSes?

I think this computer was originally winVista and then win7 and finally
win10 -- you can see where someone scratched off the OS name from the
decorative, stamp-sized windows plate on the front -- but since the HDD
is 1.5TB, T B, I figure the shop replaced the HDD and actually did
install win10 from scratch. You couldnt' get a 1.5TB drive in winV or
7, could you?


A clone should not be changing "dimensions" of the file system.

The cluster size should be the same.

It's when you do a file by file transfer, between partitions
that have different setups, that the "storage efficiency" differs
and the computed sizes differ.

Cloning on the other hand, keeps so many of these parameters
the same, you would not expect the storage size to differ.

Cloning may not choose to copy every possible folder
on the drive. What is the policy towards System Volume Information
for example ? That's a folder which is used for System Restore points
on various OSes. If cloning a C: drive, perhaps the pagefile
and hiberfile require special treatment.

To compare the visible parts of a disk, you can try hashdeep,
which can compute checksums on the source and destination drive.

Programs which have a "Verify" function, may also be able to
do a "Write, Read Verify" to help assure you that mechanically
the transfer was successful.

But some of the failings must be analyzed yourself with various
tools, to assure yourself everything is OK.

When I compared two Windows 7 installer DVDs for someone, I
used hashdeep to compare all the files, and modified one log
file so the log files could be directly compared. And that's
how I determined that the two DVDs differed in only the content
in one tiny file.

hashdeep64 -c MD5 -j 1 -r G: G_sums.txt

In that command, the -c specifies the checksum method.
MD5 is sufficient for simple comparisons and is relatively fast.
Some hashing functions with even lower probability of collision,
are a lot slower to calculate. There's no reason to assume, when
comparing "exact copy copies" of something, that trickery is
involved, and MD5 is fine for that.

The -j 1 specified one thread of execution, which tends to
make the output files discharge in the same order. Then when
you "compare" the text files, the comparison program doesn't
need to be nearly as sophisticated. On a four core processor,
a -j 4 could go four times as fast (if analyzing an SSD), if you
didn't care what order the text appeared in the output text file.

The -r means "recursive descent" and since we're passing
a whole drive G: , then all files under G: should get checked.

Since I wasn't doing a C: drive at the time, no additional
"safety" arguments need be added, such as the argument that
hops over Junction Points, or the argument that hops over
open named pipes (which stall the command and it won't finish).
Doing a C: takes a few more arguments.

To compare two data drives, you could

hashdeep64 -c MD5 -j 1 -r D: D_sums.txt
hashdeep64 -c MD5 -j 1 -r E: E_sums.txt

Then, edit E_sums.txt and change all instances
of "E:" with "D:" so that the two sums files are
"identical looking". Any checksum differences should
then stand out when you

(start bash shell in Windows 10...)
diff D_sums.txt E_sums.txt

and any different stuff will stand out.

On data disks, an *end user* really only cares
about their own files being the same. Some crappy old
System Volume Information contents isn't really a consideration.

Analyzing the two volumes down to the last electron is
not necessary in that case.

You may still be curious though, to understand why SVI
didn't get copied (would not be meaningful since shadows
of things are involved), so maybe it makes sense to not
copy them. In some cases, copying can be thwarted because
of permission issues of some sort. There are still some
items (we typically don't care about), which are almost
impossible to work with. Only the developers can access them.

You can get the hashdeep/md5deep package here. If you want
a way to compare the files where you don't have to simultaneously
read both drives. Keeping such records is also handy if you
want to re-check a volume at a later date ("tripwire" used
such a technique).

https://github.com/jessek/hashdeep/releases

https://github.com/jessek/hashdeep/r...d5deep-4.4.zip
hashdeep.exe 789,504 bytes
hashdeep64.exe 868,864 bytes

Paul

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?

Maybe you are cloning from an old disk, using 512, to a new and big disk
which uses 4K. Directly cloning may not be possible and the cloning
software you used is "intelligent" to do a translation.


--
Cheers, Carlos.

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?

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

Maybe you are cloning from an old disk, using 512, to a new and big disk
which uses 4K. Directly cloning may not be possible and the cloning
software you used is "intelligent" to do a translation.

I did think a bit about that when I first started, that at one time one
could only clone from one disk to the identical model, iirc.

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.

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.

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?

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

Maybe you are cloning from an old disk, using 512, to a new and big disk
which uses 4K. Directly cloning may not be possible and the cloning
software you used is "intelligent" to do a translation.

I did think a bit about that when I first started, that at one time one
could only clone from one disk to the identical model, iirc.

Getting the info is relatively craptastic.
This only gets the externally visible logical sector size.
The drive might be 512n, 512e, or 4Kn, as the three types.

wmic diskdrive get bytespersector,name

This one might help. All the partitions on the same drive
should be consistent. Works on Win10, doesn't work on WinXP.
Presumably some capability was added along the way.

fsutil fsinfo sectorinfo C:

Once you have the collection of numbers, you work out what
the drive type is for the purposes of explaining your hardware
to a strange. Logical is "outside", physical is "inside".
The drive plays footsie with the logical value like that,
in the name of backward compatibility. To fool the OS into
thinking a drive with internal 4KB sectors, has some different
sector size such as 512 bytes.

Type logical physical

512n 512 bytes 512 bytes (WDC Gold, Some WD RE, plus really old drives)
512e 512 bytes 4096 bytes (Majority of drives)
4Kn 4096 bytes 4096 bytes (Enterprise, *don't* buy these, no tools!)

Each Windows OS supports different logical sector sizes.
You *can* install Win10 on a 4Kn. Since I will never be
buying such a useless drive, I have no way to test.

The cluster size of the filesystem, is an entirely different
issue. NTFS operating system partitions tend to be 4096 bytes,
which means 8 logical sectors of a 512e drive are combined
together to make one "cluster". Much much larger cluster sizes
are supported. Windows 10 has some ginormous cluster choices
now - don't use them because older OSes won't recognize them!
The biggest cluster you should use is 64KB for NTFS data partitions.
The 4KB cluster size supports traditional NTFS Compression
and NTFS Encryption (EFS?). It also matches the size of paging
operations perhaps.

When you clone a drive, the cluster size will be preserved.

For a time, I (accidentally) ran Windows 10 using 64KB clusters
and at first it didn't complain. Then one day an OS upgrade
came in and "all hell broke loose". It's relatively difficult
to get good code for converting a partition between one
cluster size and another (some files could end up with
zero size, as an example of the bad things that happen if
you try).

Paul

In alt.comp.os.windows-10, on Fri, 18 Jan 2019 02:33:55 -0500, 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?

And isn't 8GB a lot to be missing? Has anyone found any lost GB?

Maybe I should wait until the whole thing finishes and see if there is a
report with error messages and explanations, but I've used the program
before and I don't remember any report, and I'd sort of expect error
messages to be in real time so if they're important the user can stop
wasting time, etc. running the program.

And when it finished it said BCD Update -- No active partition copied,
even though the first little partition is listed by MiniTool Partition
Wizard as active and system.

And the log for the partition not fully copied says no more than it said
at the time, nothing mentioned abou tthe 4 missing GB. Should I report
them missing to the police?

I had done and Intelligent Sector Copy,
Verify File System, and
Enable SSD Trim, even though this is not SSD.

No Rapid Delta because the target disk was empty, and iirc the free
version doesn't do this.



Also, the first partition, a tiny one, is only 99MB and only 32.16MB are
used. It's listed as the active, system partition. I bought the
computer used from a computer shop and this is the way it was set up. If
I started with a bare drive and installed win10 myself, would that 99MB
partition be there? Does it serve some special purpose?

Does it have something to do with multi-booting different OSes?

I think this computer was originally winVista and then win7 and finally
win10 -- you can see where someone scratched off the OS name from the
decorative, stamp-sized windows plate on the front -- but since the HDD
is 1.5TB, T B, I figure the shop replaced the HDD and actually did
install win10 from scratch. You couldnt' get a 1.5TB drive in winV or
7, could you?

micky wrote:


And the log for the partition not fully copied says no more than it said
at the time, nothing mentioned abou tthe 4 missing GB. Should I report
them missing to the police?

I had done and Intelligent Sector Copy,
Verify File System, and
Enable SSD Trim, even though this is not SSD.

No Rapid Delta because the target disk was empty, and iirc the free
version doesn't do this.


Also, the first partition, a tiny one, is only 99MB and only 32.16MB are
used. It's listed as the active, system partition. I bought the
computer used from a computer shop and this is the way it was set up. If
I started with a bare drive and installed win10 myself, would that 99MB
partition be there? Does it serve some special purpose?

Does it have something to do with multi-booting different OSes?

I think this computer was originally winVista and then win7 and finally
win10 -- you can see where someone scratched off the OS name from the
decorative, stamp-sized windows plate on the front -- but since the HDD
is 1.5TB, T B, I figure the shop replaced the HDD and actually did
install win10 from scratch. You couldnt' get a 1.5TB drive in winV or
7, could you?

You'll need to acquire a special hat.

https://images-na.ssl-images-amazon....1GcJcjHzQL.jpg

*******

https://www.storagereview.com/hard_drives_hit_15_tb

July 10th, 2008 by eugene
Hard drives hit 1.5 TB

https://en.wikipedia.org/wiki/Windows_Vista

RTM November 8, 2006

https://en.wikipedia.org/wiki/Windows_7

RTM July 22, 2009

The 1.5TB drive is between the two OSes.

*******

The 100MB partition could be a number of things.
It could be a System Reserved, but that's kinda small.

I had a setup here with GPT/EFI where the EFI partition
is 100MB. The partition is ESP (EFI System Partition).

If I had to guess, I'd probably bet on the System Volume
Information being empty on the cloned partition. There's no
particular reason to be copying shadows - I don't even know
if you're allowed to do that (Macrium or no). Macrium
probably has to skip the twitchy stuff.

I have utilities of various types, but they're not the best.

Cloning should use the same filenums on the two partitions,
so NFI might not be a total disaster. But typical usage
of NFI.exe requires cleanup of the file afterwards, to make
it easier to read and summarize. And that's not a nice feature.

The Everything.exe program can generate a filelist too,
except it misses stuff just like nfi.exe does.

This ZIP file has nfi.exe inside, and you can use the program
to "list" the two drives. Really, no utility is perfect, and
this program has four files it cannot list. Here, I'm listing
the contents of the C: drive. You can list your source and
destination partitions and compare them.

https://web.archive.org/web/20150329...us/oem3sr2.zip

(administrator command prompt)

cd /d %userprofile%\Downloads
nfi.exe c: list.txt
notepad list.txt

I'm trying to keep this simple, so you'll at least
have some opportunity to look at stuff. Most of the utilities
aren't focused on a particular job, which makes massaging
the output difficult.

Paul

In alt.comp.os.windows-10, on Fri, 18 Jan 2019 17:50:58 -0500, Paul
wrote:

.......

https://www.storagereview.com/hard_drives_hit_15_tb

July 10th, 2008 by eugene
Hard drives hit 1.5 TB

https://en.wikipedia.org/wiki/Windows_Vista

RTM November 8, 2006

https://en.wikipedia.org/wiki/Windows_7

RTM July 22, 2009

The 1.5TB drive is between the two OSes.

*******

The 100MB partition could be a number of things.
It could be a System Reserved, but that's kinda small.

I had a setup here with GPT/EFI where the EFI partition
is 100MB. The partition is ESP (EFI System Partition).

If I had to guess, I'd probably bet on the System Volume
Information being empty on the cloned partition. There's no
particular reason to be copying shadows - I don't even know
if you're allowed to do that (Macrium or no). Macrium
probably has to skip the twitchy stuff.

I have utilities of various types, but they're not the best.

Cloning should use the same filenums on the two partitions,
so NFI might not be a total disaster. But typical usage
of NFI.exe requires cleanup of the file afterwards, to make
it easier to read and summarize. And that's not a nice feature.

The Everything.exe program can generate a filelist too,
except it misses stuff just like nfi.exe does.

This ZIP file has nfi.exe inside, and you can use the program
to "list" the two drives. Really, no utility is perfect, and
this program has four files it cannot list. Here, I'm listing
the contents of the C: drive. You can list your source and
destination partitions and compare them.

https://web.archive.org/web/20150329...us/oem3sr2.zip

(administrator command prompt)

cd /d %userprofile%\Downloads
nfi.exe c: list.txt
notepad list.txt

I'm trying to keep this simple, so you'll at least
have some opportunity to look at stuff. Most of the utilities
aren't focused on a particular job, which makes massaging
the output difficult.

Paul

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.

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.

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

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.

So how "powerful" is the DOS dir command ?

Cloning OS drives is a lot more demanding on forensics.
It's a lot harder to compare the original and clone.

Not many things are going to get inside the
System Volume Information folder.

When you do Properties on C: and get a pie chart
or a circle chart, that's the only exact sizing
command for C: . Other attempts to use virtually
any other utility, will get wrong size information.

You would expect a clone though, to be "identical",
so whatever sizing command you use, should make the
same mistakes on both volumes.

********

One way to examine a C: partition, might be to back up
a partition with Macrium, to a .mrimg, then right-click
it and mount it. There's a tick box in the dialog to
give "unrestricted access" on the thing when it mounts.
Running your "dir" against the mounted backup should
then give a more complete listing of files (if they're
present).

This is a dumb idea and a lot of work, but I don't
really have a lot of other tools that come with
guarantees for jobs like this.

C: -- backup to .mrimg --- mount as Q:
D: -- backup to .mrimg --- mount as R:
dir Q: # fewer restrictions to prevent access
dir R: # fewer restrictions to prevent access

Psul

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.


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.


--
Cheers, Carlos.

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).

--
Cheers, Carlos.

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

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.

Paul

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.

--
Cheers, Carlos.