I wanted to know if Robocopy could replace synchronization programs like GoodSync and Allway Sync. I decided to take a look at its options. This post describes what I found.
The manual for Robocopy itself seemed to confirm my prior sense that Robocopy was a unidirectional copying utility. That is, you could command it to copy from A to B, or from B to A, but not bidirectionally between A and B, never mind multidirectionally. In particular, manual page 16, discussing Robocopy's /XO option, said this:
The most appropriate use for /XO is to synchronize two directory trees so that they can be updated simultaneously in separate areas. To ensure that the latest files are present in both directory trees, copy with /XO first in one direction and then in the other.So apparently synchronization with Robocopy would require reciprocal commands: one to copy newer files from A to B, and another, otherwise identical, command to copy from B to A. Wikipedia noted that Robocopy would not copy open files, but that seemed to be true of GoodSync as well. I didn't expect it to be a problem for my purposes.
(The information from the manual seemed pretty similar to what I got from a command-line "robocopy /?" command. A Windows Server webpage provided yet another list of Robocopy commands. I had noticed, though, that Wikipedia said Robocopy was not entirely consistent between platforms. It seemed I had better verify that my solutions would work on Windows 7 specifically.)
I wasn't yet sure what kind of analysis /XO or other Robocopy commands would perform. I assumed, but was not yet positive, that they would take account of time as well as date, down to the minute if not the second. This thought prompted me to look into something that would improve the present gap of about 20 seconds between the clocks on the two computers -- something more fun than just resetting the clock manually, that is. It seemed I would want one or two minutes' tolerance in timestamp comparisons in any case; but in a separate post, I took a closer look at possible solutions to get the two machines closer to chronological synchronization. (Later I saw that the manual (p. 17) said, "File-time granularity is 100 nanoseconds on NTFS, and two seconds on FAT.")
The next step seemed to be to peruse the Robocopy command-line options, to see which ones might work for my synchronization project. The manual (pp. 7-11) provided a concise command-line reference. (Apparently lowercase versions of the commands worked; I use uppercase here for visibility.) The options that seemed most relevant were as follows, leaving out those that would be included by default:
/S copy subdirectories, excluding empty onesThis was an intimidating set of potentially relevant options. There were many things that could go wrong with so many choices. I decided to look for examples and more information. As the manual said (p. 22), these options could result in long, unwieldy commands, and it did appear that the JOB options would help with that. I ran a search with that in mind. It led most immediately to some general-reference sites (e.g., SS64, PowerCram, FixMyITSystem). I tried again. That search led almost nowhere. Likewise another, seemingly broader search.
/ZB resume a copying task from a point of previous failure (presumably instead of starting over), but switch to backup mode if restartable mode fails (as when using an unreliable network); but Wikipedia said that /Z would slow copying significantly
/MOT:X and /MON:Y monitor the source directory and run Robocopy again when X number of files have changed and Y minutes have elapsed
/XD exclude specified directories
/XO don't overwrite destination files with source files having the same name and an older timestamp
/R specify the number of retries
/W specify wait time between retries
/REG save /R and /W in registry as default settings
/L list files
/V produce verbose output
/TS display source file timestamps in output log
/FP display full pathnames in output log
/NC suppress output of Robocopy file class information
/NS suppress output of file and directory sizes
/NJH and /NJS turn off logging of job header and summary
/ETA show estimated time of completion
/LOG:filename or /LOG+:filename redirect output to named file, overwriting or (+) appending if it already exists
/TEE display output as well as writing LOG
/JOB:jobfile read parameters from jobfile; optionally /IF to include files with specified names or paths; optionally /SD:path and /DD:path to specify source and destination directories; optionally /QUIT to view job file contents without any actual copying
/SAVE:jobfile write current parameter settings to jobfile
Eventually, I found an eHow website that said I could use XCopy to synchronize computers. Was I trying to use the wrong tool? It didn't seem so. I saw indications that Robocopy had more options and better performance, and that use of XCopy was deprecated. But why was I not seeing tons of obvious references to the use of Robocopy JOB options for synchronization? (Another possibility with lots of options: XXCOPY. But the least expensive version for networked computers cost $100, and its reception at CNET was underwhelming.)
I tried another search, focusing only on Robocopy job options. Posts at Serverfault and Skonet seemed to suggest that I could work up my desired Robocopy command on the command line itself, and then add the /SAVE option to save it to a file, and that my job options would go into a separate file with an .RCJ extension. I wasn't sure exactly how all that would work in practice, but at least there seemed to be a starting point.
It appeared that the slash (/) character was the signal, in the job options file and probably also for Robocopy generally, indicating that one option had ended and a new one was starting. So, for instance, if I gave the /XD command, I could then proceed to list a boatload of directories to exclude, without worrying too much about format -- putting them on the same line, putting each on a different line, or whatever. Everything I wrote after /XD would be treated as another directory to exclude, until I came to another / command (e.g., /S) or else reached the end of the job options file.
One thing that was not clear to me, from the foregoing options: what if I had deleted a file on computer B, intending that synchronization should delete it on computer A as well? GoodSync knew how to interpret such situations. I suspected that Robocopy, run in a reciprocal setup starting with robocopy A > B, would just restore the file from computer A to computer B. That, as I found in tinkering, was what Beyond Compare might do. In other words, there was a real difference between a backup program and a synchronization program. The former would just make sure that the target contained what was on the source; the latter would keep track of what had been removed from each side, and would decide whether the removal occurred later than the most recent update of those files on the other side. I could control such things manually, more easily in Beyond Compare than in robocopy, but for an automated solution I would need a program that would keep track of dates and times of deletions as well as of file changes. I posted a question on this, just to make sure I was understanding Robocopy correctly. The response confirmed it, and suggested using regular synchronization programs.