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 |
#16
|
|||
|
|||
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. |
Ads |
#17
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#18
|
|||
|
|||
I cloned the partition and it's not the same size!!
|
#19
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#20
|
|||
|
|||
I cloned the partition and it's not the same size!!
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 |
#21
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#22
|
|||
|
|||
I cloned the partition and it's not the same size!!
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 |
#23
|
|||
|
|||
I cloned the partition and it's not the same size!!
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 |
#24
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#25
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#26
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#27
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#28
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#29
|
|||
|
|||
I cloned the partition and it's not the same size!!
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. |
#30
|
|||
|
|||
I cloned the partition and it's not the same size!!
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? |
Thread Tools | |
Display Modes | Rate This Thread |
|
|