Retries

Most file system operations that that fail and return an error will cause the program to wait and then retry the operation until it succeeds or the retry limit is reached. By default there will be 30 seconds between retries, and up to one million (1000000) retries. Use /W:n to change the wait time in seconds between retries, and /R:n to change the retry limit, where n is a positive decimal integer, or zero if you do not want retries or wait times between retries. If invalid values are given for /W or /R, the respective default value is used.

To change the default retry parameters, use the /REG switch on a valid Robocopy command that specifies non-default values for /W and /R. When /REG is used, the values you specify for /W and /R will be stored in the Registry and used as default values for /W and /R in future Robocopy runs where /W and /R are not specified on the command line. Simply specify /W and/or /R on the command line to override the stored settings.

Note that certain errors in some operations will not be retried, where practical experience indicates this would be futile. For example, an error of "Network Name Not Found" usually indicates that a remote computer exists, but does not have a sharepoint with the given name. As manual intervention will be required to correct this (by creating a suitable sharename on the remote computer), this error is generally not retried, and the attempted operation fails.

However, in some instances, this might not be the correct action for this error. For example, in a software publishing environment it is quite common to delete a sharename, update the contents of the sharepoint, then recreate the sharename. In this situation you should use the /TBD switch, which instructs the program to retry when it encounters a "network name cannot be found." error, on the assumption that we are waiting for the sharename to be defined.

Normally Robocopy will restart failed copies from the beginning of the file. You can override this default behaviour by specifying the /Z switch, which requests restartable copies - with /Z, failed copies will restart from close the point of failure rather than the beginning of the file. There is one exception to this - if the file's size or timestamp is modified between retries, the file has obviously been changed, and the copy is restarted from the beginning of the file.