I've read through the other posts I've found, but my experience seems to be different. I am definitely not a superuser and I inherited the Robocopy process we use, but in the nutshell, I map a network driver and use Robocopy with "/s /e /z /xc /xn /r:100 /w:5 /log:" commands. (I cannot for the life of me figure out why "/s" and "/e" are used, seems to counter each other. Anyway, we are often transferring 1GB files over a long slow network that can drop out. The first time, it got to ~7% of the file and then the connection dropped. When I started Robocopy again, it skipped the large file instead of resuming. I can't seem to get the resume to work properly. The next time it got to 26.7%, but the file has all the right attributes to appear it's a full file. The date, the file size, etc.

Is there a way to get this working instead of starting from 0% every time? Maybe it has something to do with the file type being an encrypted batch of files, but still.

  • Why is it using "/xn : Source directory files newer than the destination are excluded from the copy".
    – harrymc
    Apr 4, 2023 at 16:01

1 Answer 1


Here are a few things you can try:

  • Increase the retry count. The /r parameter controls the number of retry attempts. Increasing this to a higher number, like /r:200 or more, may allow Robocopy to eventually resume the transfer.

  • Increase the wait time between retries. The /w parameter controls this. A higher wait time, like /w:30, gives the network connection more time to recover between retries.

  • Use Checkpoint Restart. The /z option enables checkpoint restart, which saves state information about the transfer so it can be resumed from the last checkpoint. However, it sounds like this may not be working fully in your case. You may need to disable this (/z-) and instead...

  • Use file attributes as a checkpoint. Since you said the file size and date are updating, you can use that as a checkpoint to resume from. Run Robocopy initially with /z- to disable its checkpoint feature. Then, when the transfer fails and restarts, compare the source and destination file sizes and modification dates. Use the /mov option to skip copying the portion that has already been transferred.

For example:

robocopy \\source\share c:\destination\folder /s /e /r:200 /w:30 /z- 

This will start the initial transfer without checkpoints. If it fails and restarts:

robocopy \\source\share c:\destination\folder /s /e /r:200 /w:30 /z- /mov 

The /mov option will move (skip) files that have the same size and modification date, effectively resuming from where you left off.

I hope one of these options helps

  • On the other hand , you can easily use Freefilesync , Teracopy , Gs Richcopy , Syncaback , Duplicati or any alternative to Robocopy to also handle this issue
    – charlote44
    May 8, 2023 at 11:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .