Synctoy 1.4 used to crash and Synctoy 2.0 got stuck at about 60-70% when attempting to sync a 'small' 30 gig folder.
OK, it's Nov09 and SYNCTOY 2.1 is released. !!!!
Let's test to see if it can handle copying data from my source folder to a destination.
The main reason I would like to use Synctoy rather than using Robocopy is to avoid unnecessarily recopying files and folders that you may have moved or renamed - which should provide a vast speed improvement over using a simpler utility like robocopy.
To summarise the results below for Synctoy 2.1 testing:
-> Good news is that Synctoy no longer crashes, and no longer gets stuck.
-> Bad news is that if you use Synctoy 2.1 and create a new folder pair for a source and destination folder that ALREADY EXIST (and are already perfectly synchronised using something like robocopy or perhaps by using synctoy 1,2 or 2.1 using a previous folder pair), then it completely fails to recognise subfolders that you subsequently move or rename and it ends up copying them all over again, leaving BOTH in the destination.
The following tests are using the 'Echo' feature of Synctoy 2.1.
This PC is an Intel Quad core 2.5GHz with 3g ram running Vista Ultimate 32bit.
My test folder is 184g (242,616 files in 9096 folders)
I'm still using robocopy to handle my backup to external usb drive; once the drives are synced if I do a second pass robocopy takes just 4.5 seconds to whizz through the 242,616 files and show that there's nothing left to copy.
Using Synctoy 2.1 I created a new folder pair for this pair of folders using echo with standard options, and clicked Preview.
On the first pass I did think it was stuck at 60% but it carried on without problem taking 1 hour and 22 minutes. That's quite reasonable considering synctoy 2.0 got completely stuck on a folder a sixth of the size. It has now created a database representing the file structure which should allow it to identify folders or files that were renamed, ultimately avoiding hours and hours of unnecessary copying and network traffic. It looks promising.
Strangely, out of the 242,616 files it did identify 15 files from two folders that needed updating, even though I ensured the folders were completely in sync before I started.
I just used WINDIFF to check the source and target subfolders that contain these particular 15 files. Yup - the files in this folder are definitely identical, so I don't know why synctoy has identified that these files need to be overwritten. (The source and destination drives are both local and both NTFS).
OK, I let it run anyway, despite showing me it had 15 files to copy from d: to f:, it just actually only did 6 overwrite operations - no other operations, (and 485,146 files did not require action which is presumably around 242+ thousand files on D and a similar number on F)
I windiffed the two folders again and all the files still match.
OK, let's see how long synctoy 2.1 takes now on the second pass... there should be nothing to sync. Wow... it took 2 mins 40 seconds - that's not bad at all ! Did another preview - now 2 mins 5 seconds.
So it's thumbs up for Synctoy 2.1 in terms of speed of working out its tasks, not getting stuck and not crashing.
Right, here's the big test for Synctoy 2.1:
Inside this 184g folder is a subfolder that contains 11.7gb and over 56,500 files including 1799 folders. I'll now rename that subfolder on the source drive and then attempt to sync again with Synctoy. Other methods of syncing including the robocopy script with the /MIR switch would delete the 11.7 gb from the destination and copy the 11.7gb all over again. Synctoy should recognise the name change and just rename the destination folder taking no time at all, though I appreciate it might accomplish it by doing 56,500 separate move operations - (which should still be a lot quicker than copying the 56,500 files! )
I clicked Preview to kick of the echo operation again. It came up with a vast number of delete and new operations and only a few renames. The preview took 35 mins 29 seconds and in total it found 76,738 actions to perform !!
That's a big fail for Synctoy 2.1. What's the point of spending well over an hour to make that database on the first pass if it's not going to detect a single folder rename?
I then let it run - but I eventually stopped it when it had done over 19,000 operations after about an hour. I manually moved the folders back that it was copying unnecessarily and then deleted the 13186 files (2gig) that it had created so far in the destinations recycle bin.
OK, I can't trust synctoy now to get this right because I've messed about manually with the destination folder. To get the destination perfectly identical to the source without deleting the destination and starting all over again, I used Robocopy with the /mir switch. OK, the destination is now exactly the same as the source.
I then ran the preview once again on that large area but it now says there are 323 folders to delete, 6186 files to delete, 6186 new files and 323 new folders. OK, actually, while doing my previous testing, I did do a few renames of other subfolders in both the source and the destination. They do match perfectly, confirmed by robocopy, but of course synctoy has a database that reflects what it saw in the source folder the last time I ran it... so presumably it sees the changes I made and thinks it has a load of work to do, when in fact there is none to do. I'm not sure I like this idea of how synctoy checks against a database that it created last time - I think it really needs to check all of the destination files and folders each time. It's really making the assumption that the destination is only ever changed by synctoy, not allowing for manual copying or editing of files, nor for renaming of folders on anything but the original source.
If I could remember all of the folder names that I renamed and put them all back again, I'm sure Synctoy would then be happy. But the only way to sort this mess out now and avoid Synctoy attempting to perform all unnecessary moves and renames is to delete this folder pair, recreate it and run the preview again. I did this and after waiting for the hour and a half processing, confirmed it now shows 0 files to copy.
Let's test Synctoy 2.1 with something much much simpler.
I created a folder d:\test with 3 subfolders a,b, and c. They all have files, but folder b has 2 further subfolders called fff with 12 files and 2 further subfolders, and ggg in which there are 7 files.
Let's sync that to f:\test using echo.
The preview took under a second. The run took 14 seconds.
Ran it again - took under a second to show that there are zero files to copy.
Right, I now manually rename folder b to t
The preview again takes under a second and shows 5 folders to delete, 67 renames and 5 folders to create and it ran this in 1.5 seconds.
Well that worked perfectly... That said, it's a shame it doesn't realise it can just perform a single rename on the top level folder and instead do individuals moves of every file within! But what went wrong with my large folder .. is it just a matter of folder size that confuses Synctoy ?
I'll try a smaller folder within the 140 gig structure. This folder contains 17 files, 164meg and includes one subfolder. OK, it got that right.... just rename operations and create folders.
Let's try another folder - 194 files, 1.25 gig including 74 subfolders - it got that right too apart from 2 files which it decided to delete and recopy.
Now try another folder - 902 files, 5.22 gig including 572 subfolders. Now it's starting to go wrong. It came up with 209 folders to delete and create, 332 files to delete, 571 files to rename (move), 332 smallish files to delete and recopy - (totalling 75 meg). In this case that wouldn't take too long, but why is it doing this?
Now a bigger folder - 6760 files , 15.99 gig including 2162 subfolders. It came up with 739 folders to delete and recreate, 5775 files to rename (move), 1051 files to delete and re-copy totalling 103meg. Again, interesting it is choosing small files to recopy. I checked out some of these files - they're not read only. Perhaps I have a clue.... these files are all from a small set of subfolders.
I'll try setting up a new sync pair using one of these subfolders that it decided to delete/copy rather than rename/move.
This folder structure is 1174 files, 80 meg and contains 389 subfolders. I'll start off with the folder names being the same; the preview ran very quick and showed nothing to change. OK, change the subfolder in question inside the source folder - YES - it again says these are new files. The patch is very long... I'll subst a pair of drive letters for the source and destination a long way down the path so that the folders are no longer long. This'll tell us if it's something to do with the contents of the folders, or just a problem with path length. It still says 179 new files to copy.
I substed a pair of drives letters as close as possible to the folder in question and it still showed 179 new files to copy.
In case it's something to do with the files themselves, or their names, I'll copy them to a simple test folder d:\test - then I'll rename the single subfolder inside. It still shows new files to copy. This is now a simple folder with a single subfolder. Still the same problem.
Now let's just go back to creating a very small test folder with just 2 subfolders and 1 file similar to the successful test I did before. Well now this causing trouble with synctoy. I can't work out why sometimes it successfully renames/moves files, and other times it wants to copy a new file (and sometimes doesn't delete the original leaving 2 copies in the destination). [EDIT - I've since discovered this occurs only if the destination folder already exists when you created the synctoy pair. It never goes wrong if you let synctoy copy the entire source to an empty destination folder on the first run..... but this means you can never delete and recreate the folder pair unless you delete the entire destination folder as well].
I'll try one more - with my pics folder - 28024 files, 62 gig, already robocopied to the destination folder. The preview operation successfully shows nothing to copy. Renamed a subfolder one level down, and another subfolder at level 2. It's got the whole lot wrong, synctoy wants to copy 1608 files totalling 4.6 gig. If I completely close synctoy, reload and try again, the results are the same.
I'm afraid Synctoy 2.1 echo just doesn't work ! I really was hoping that Synctoy2.1 would be a winner. The fault may lie within Synctoy itself or within Microsoft Sync Framework on which Synctoy is based - so you'd have to test other products based on sync framework to see if the same problem exists in them.
Most people will assume that synctoy would work without problem so I guess a lot of time is going to be wasted; I've just spent 6 hours trying to get it to work properly myself. I hope MS can come up with an update to Synctoy and/or Sync Framework asap.
Tim from howeasyisthat.com and brisbanepc.com.au
[I've made a number of edits mainly to make this easier to read,
and to include a summary of the findings right at the top]Read more...