66

I'm kind of new to batch scripting. As a newbie I find both both of them useful while scripting What are the key differences between xcopy and robocopy?

tourist
  • 3,447
  • 5
  • 19
  • 41

6 Answers6

76

Robocopy replaces XCopy in the newer versions of windows

  1. Uses Mirroring, XCopy does not
  2. Has a /RH option to allow a set time for the copy to run
  3. Has a /MON:n option to check differences in files
  4. Copies over more file attributes than XCopy

Yes i agree with Mark Setchell, They are both crap. (brought to you by Microsoft)


UPDATE:

XCopy return codes:

0 - Files were copied without error.
1 - No files were found to copy.
2 - The user pressed CTRL+C to terminate xcopy. enough memory or disk space, or you entered an invalid drive name or invalid syntax on the command line.
5 - Disk write error occurred.

Robocopy returns codes:

0 - No errors occurred, and no copying was done. The source and destination directory trees are completely synchronized.
1 - One or more files were copied successfully (that is, new files have arrived).
2 - Some Extra files or directories were detected. No files were copied Examine the output log for details. 
3 - (2+1) Some files were copied. Additional files were present. No failure was encountered.
4 - Some Mismatched files or directories were detected. Examine the output log. Some housekeeping may be needed.
5 - (4+1) Some files were copied. Some files were mismatched. No failure was encountered.
6 - (4+2) Additional files and mismatched files exist. No files were copied and no failures were encountered. This means that the files already exist in the destination directory
7 - (4+1+2) Files were copied, a file mismatch was present, and additional files were present.
8 - Some files or directories could not be copied (copy errors occurred and the retry limit was exceeded). Check these errors further.
16 - Serious error. Robocopy did not copy any files. Either a usage error or an error due to insufficient access privileges on the source or destination directories.

There is more details on Robocopy return values here: http://ss64.com/nt/robocopy-exit.html

Nicolas Tyler
  • 9,372
  • 4
  • 38
  • 62
  • 2
    Much more constructive than my answer, but far less fun :-) – Mark Setchell Jun 09 '14 at 13:24
  • 7
    Note that XCopy returns a standard exit code (zero on success, nonzero on failure) while Robocopy does not. – Gerald Combs Apr 13 '15 at 15:25
  • is there any (free and/or open source) better solution for auto backup files in a windows server to another windows server? My Company has too much windows server, and they don't give me money to buy any license for this task. – Luke Aug 04 '18 at 04:44
  • 1
    I can tell you one f..kin big difference I've just had 3 minutes ago: you go to a directory on your network. Shift-Right click "open powershell here". Then try "`robocopy "." "D:\tmp\" /MOV`" (**`D:`** is a physical hard drive). This work. Turn off the computer that shares that directory (while copying). This won't work with tons of errors, press CTRL-C and try again. `robocopy` has tried to move all the files from the `C:\Windows\System32` directory. True. You can't do that with `xcopy`. – Olivier Pons Aug 10 '18 at 22:12
  • @OlivierPons, I can repro. Definitely a bug in Powershell, the same thing happens with any external command, not just robocopy. That means it isn't really relevant to this question because the OP is programming in batch, not in Powershell, but if you *must* use Powershell then you could use its Copy-Item or Move-Item cmdlets instead of external tools, or you could give robocopy the fully qualified path. – Harry Johnston Aug 12 '18 at 23:11
  • Sorry for being angry, but after more than 20 years, still not being able to make a command-line utility that moves files *safely* in totally un-professional. Linux for the win. – Olivier Pons Aug 12 '18 at 23:35
  • @OlivierPons, understandable, I just wanted to clarify that the problem wasn't in robocopy so using a third-party command-line tool wouldn't help. [As for the Powershell issue, I've filed a bug report,](https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/35094757-problem-with-external-commands-when-current-locati) but I'm not going to hold my breath. – Harry Johnston Aug 12 '18 at 23:44
18

The most important difference is that robocopy will (usually) retry when an error occurs, while xcopy will not. In most cases, that makes robocopy far more suitable for use in a script.

Addendum: for completeness, there is one known edge case issue with robocopy; it may silently fail to copy files or directories whose names contain invalid UTF-16 sequences. If that's a problem for you, you may need to look at third-party tools, or write your own.

Harry Johnston
  • 33,445
  • 6
  • 56
  • 142
  • 1
    Can you link to documentation that describes this behavior? – Dan Solovay Jun 23 '16 at 18:57
  • With what I've just had I'll never use `robocopy` again. Never ever. Not safe at all. Microsoft should finish properly such programs before releasing it. You copy from the network, the network is down, then it tries to move files from where it is and... it's `C:\Windows\System32`. Good job Microsoft, after 20 years still not able to make a program that moves properly files. I'll show this example to my students so they'll understand why they have to go to Linux. – Olivier Pons Aug 10 '18 at 22:37
  • @OlivierPons, I've been using robocopy for twenty years and never had any problems. Certainly it has never copied files to or from the wrong place! Can you explain in more detail what you think went wrong and how to reproduce it? – Harry Johnston Aug 10 '18 at 23:47
  • So in 20 years you've just never had network problems while copying. You're lucky, end of story. And read all comments and answers about `xcopy` vs `robocopy`... they talk by themselves. – Olivier Pons Aug 11 '18 at 10:06
  • @OlivierPons, of course I have - that's the whole *point* of using robocopy, because it keeps going after a network glitch instead of stopping dead. – Harry Johnston Aug 12 '18 at 00:45
  • ... for completeness, there *is* one known issue with robocopy when dealing with filenames that contain invalid UTF-16 sequences, but that's likely to be an issue with most third-party tools as well. I'll add a note to my answer anyway. (And as already mentioned, your problem was probably caused by Powershell rather than by robocopy. Microsoft's fault either way, of course.) – Harry Johnston Aug 12 '18 at 01:12
  • Sorry for being angry, but after more than 20 years, still not being able to make a command-line utility that moves files *safely* in totally un-professional. Linux for the win. – Olivier Pons Aug 12 '18 at 23:35
  • 1
    For the benefit of future readers, [Olivier's problems were caused by Powershell, not Robocopy](https://stackoverflow.com/questions/24121046/difference-between-xcopy-and-robocopy/24132239#comment90581885_24121244). – Harry Johnston Jan 29 '20 at 18:39
10

The differences I could see is that Robocopy has a lot more options, but I didn't find any of them particularly helpful unless I'm doing something special.

I did some benchmarking of several copy routines and found XCOPY and ROBOCOPY to be the fastest, but to my surprise, XCOPY consistently edged out Robocopy.

It's ironic that robocopy retries a copy that fails, but it also failed a lot in my benchmark tests, where xcopy never did.

I did full file (byte by byte) file compares after my benchmark tests.

Here are the switches I used with robocopy in my tests:

 **"/E /R:1 /W:1 /NP /NFL /NDL"**.  

If anyone knows a faster combination (other than removing /E, which I need), I'd love to hear.

Another interesting/disappointing thing with robocopy is that if a copy does fail, by default it retries 1,000,000 times with a 30 second delay between each try. If you are running a long batch file unattended, you may be very disappointed when you come back after a few hours to find it's still trying to copy a particular file.

The /R and /W switches let you change this behavior.

  • With /R you can tell it how many times to retry,
  • /W let's you specify the wait time before retries.

If there's a way to attach files here, I can share my results.

  • My tests were all done on the same computer and
  • copied files from one external drive to another external,
  • both on USB 3.0 ports.

I also included FastCopy and Windows Copy in my tests and each test was run 10 times. Note, the differences were pretty significant. The 95% confidence intervals had no overlap.

SixSigmaGuy
  • 133
  • 1
  • 7
  • 1
    You answer is a little difficult to read, you should format it a bit more. You can use \` for `inline` code \` (its the squiggle/tilde key that looks like this: ~) and enter twice for a new paragraph. – Xander Luciano Aug 15 '16 at 20:49
  • Sorry, When I wrote it, it had blank lines to separate things. – SixSigmaGuy Aug 17 '16 at 02:19
  • I had a lot of problems with ROBOCOPY failing because people used to delete user accounts from Active Directory when they left the company, and their SIDs were the owners of some files or in their DACLs. Whenever robocopy hit such a file it would crash. It was a nightmare. – Spencer May 20 '21 at 13:02
3

Its painful to hear people are still suffering at the hands of *{COPY} whatever the version. I am a seasoned batch and Bash script writer and I recommend rsync , you can run this within cygwin (cygwin.org) or you can locate some binaries floating around . and you can redirect output to 2>&1 to some log file like out.log for later analysing. Good luck people its time to love life again . =M. Kaan=

  • Or go for Linux forever as well. Better choice IMHO. – Olivier Pons Aug 11 '18 at 10:07
  • After 2-3 with Robocopy which looks good at first, I'll try rsync. Robocopy has horrible issues, the summary is totally wrong, the default value for multi-threading is mostly totally wrong/slow for all stuff i copied, resume didn't work. Just take a look at the github repo and the issue, it's far from a good product. It even overwrites System Volume Info and the recovery dir and destroys the drives. Unbelievable. – 98percentmonkey Nov 19 '18 at 11:13
1

I have written lot of scripts to automate daily backups etc. Previously I used XCopy and then moved to Robocopy. Anyways Robocopy and XCopy both are frequently used in terms of file transfers in Windows. Robocopy stands for Robust File Copy. All type of huge file copying both these commands are used but Robocopy has added options which makes copying easier as well as for debugging purposes.

Having said that lets talk about features between these two.

  • Robocopy becomes handy for mirroring or synchronizing directories. It also checks the files in the destination directory against the files to be copied and doesn't waste time copying unchanged files.

  • Just like myself, if you are into automation to take daily backups etc, "Run Hours - /RH" becomes very useful without any interactions. This is supported by Robocopy. It allows you to set when copies should be done rather than the time of the command as with XCopy. You will see robocopy.exe process in task list since it will run background to monitor clock to execute when time is right to copy.

  • Robocopy supports file and directory monitoring with the "/MON" or "/MOT" commands.

  • Robocopy gives extra support for copying over the "archive" attribute on files, it supports copying over all attributes including timestamps, security, owner, and auditing information.

Hope this helps you.

Dulith De Costa
  • 8,429
  • 1
  • 53
  • 43
  • When you use /RH does that mean the command will always run at that time without any interaction, even after restart? – S.Ramjit Nov 15 '20 at 23:11
-9

They are both rubbish! XCOPY was older and unreliable, so Microsoft replaced it with ROBOCOPY, which is still rubbish.

http://answers.microsoft.com/en-us/windows/forum/windows_8-files/robocopy-appears-to-be-broken-in-windows-8/9a7634c4-3a9d-4f2d-97ae-093002a638a9

Don't worry though, it is a long-standing tradition that was started by the original COPY command, which to this day, still needs the /B switch to get it to actually copy properly!

Mark Setchell
  • 146,975
  • 21
  • 182
  • 306
  • 5
    `copy` defaults to `/b` on binary files now. I'm not sure where you get your hatred of robocopy from... your link just shows that the `archive` attribute is being utilised as it is designed. – foxidrive Jun 10 '14 at 03:59
  • 1
    Robocopy works perfectly well up to and including Windows 7. If it has been broken in Windows 8 ... well, that doesn't actually surprise me much. Maybe Windows 10 will be better. – Harry Johnston Jan 23 '15 at 21:49
  • 7
    Can you be a little more constructive and suggest an alternative please? – Mark Cooper Jun 17 '15 at 16:37
  • 2
    @MarkCooper Yes, either install Linux or install VirtualBox and put Linux on the VirtualBox then use `rsync` or `cp`. – Mark Setchell Jun 17 '15 at 16:48
  • 12
    @MarkSetchell Terrible answer. Judging by your rep you should know better. – Mark Cooper Jun 17 '15 at 17:28
  • 2
    @MarkCooper The answer addresses the question which, to remind you, asked about *"the differences"* not to recommend an alternative. My answer is that there is little difference because both tools are poor - and I stand by that answer. If you have a different question, please ask it as a new one instead of piggybacking off other people's questions. – Mark Setchell Jun 17 '15 at 17:50
  • 10
    @MarkSetchell you have not answered OP's question, instead giving your own opinion about how much you dislike XCOPY and ROBOCOPY. This isn't fact, it isn't constructive and does nothing to help OP. – Mark Cooper Jun 18 '15 at 09:12
  • 3
    i don't see this answer as `hatred`. I see humor in it. And god knows why there have to be 3 versions of a command that does copy function. copy, xcopy & robocopy... why not build on the single copy? For any new block to windows world of scripting. this is making a steep learning curve unlike the shell programming. – OK999 Jan 20 '16 at 16:59
  • 7
    @OK9999: it makes sense once you know the history. Both `copy` and `xcopy` were part of DOS, and they had to be separate because `copy` was an internal command and `xcopy` an external one. Windows included them both for backwards compatibility. The `robocopy` command was originally developed by a separate team, initially for internal use and later as part of the resource kit. It didn't become a built-in part of Windows until later on. (I'm also dubious about the claim that shell programming doesn't have a steep learning curve. The syntax is pretty darned abtruse!) – Harry Johnston Apr 11 '16 at 21:17