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. |
|
|
Thread Tools | Rate Thread | Display Modes |
#31
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 |
|
|