5

We're using robocopy (file version 5.1.10.1027) to mirror directory trees. robocopy is called by a python script rather than manually. We're relying on robocopy's exit codes to determine whether the operation was successful or not. If successful, our script proceeds to do a lot of other fancy stuff. Else it aborts immmediately.

Allegedly, robocopy's exit code is a bit field with the following flags (https://ss64.com/nt/robocopy-exit.html):

Hex Decimal Meaning if set

0×00   0       No errors occurred, and no copying was done.
               The source and destination directory trees are completely synchronized. 

0×01   1       One or more files were copied successfully (that is, new files have arrived).

0×02   2       Some Extra files or directories were detected. No files were copied
               Examine the output log for details. 

0×04   4       Some Mismatched files or directories were detected.
               Examine the output log. Housekeeping might be required.

0×08   8       Some files or directories could not be copied
               (copy errors occurred and the retry limit was exceeded).
               Check these errors further.

0×10  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.

Going by this information, any exit code greater than 7 can be assumed to mean that at least one error occurred, so this is the criterion our script uses to determine whether robocopy succeeded.

Now we've run into an issue where robocopy fails to delete a file in the destination that is no longer present in the source, due to an access-denied problem:

  *EXTRA File            661    AdminTable_version.h
  2017/06/13 02:38:08 ERROR 5 (0x00000005) Deleting Extra File E:\fw_cu\build\output\AdminTable_version.h

Access is denied.

but then returns with an exit code of 3 anyway. In other words, flags 0x01 and 0x02 are set, meaning:

One or more files were copied successfully (that is, new files have arrived).

and

Some Extra files or directories were detected. No files were copied
Examine the output log for details.

We're using the following command line:

robocopy.exe M:\fw_cu E:\fw_cu /MIR /FFT /W:5 /NP

Now, unless I'm missing something, these exit code flags either do not convey enough information to reliably tell whether the operation was 100% successful, or robocopy is simply not using them consistently. I feel like failure to delete at least one file during a mirroring operation would warrant either the 0x08 or the 0x10 flag.

antred
  • 3,697
  • 2
  • 29
  • 37
  • You haven't specified the `/R` so the operation will be retried until it succeeds. If you examine the log carefully, I think you'll find that the operation failed once, but succeeded after one or more retries. The exit code does not report this sort of transient error. PS: mismatched files/directories should usually be treated as an error condition, so you should consider an exit code greater than 3 to be a failure. – Harry Johnston Jun 13 '17 at 23:34
  • @HarryJohnston Hello Harry. No, the operation was not repeated and it never succeeded. To be frank, it couldn't have, since the current user simply lacked permissions to delete those files. – antred Jun 14 '17 at 14:22
  • Also, why should mismatched files / dirs be treated as an error? It is my misunderstanding that robocopy, if invoked with the /MIR switch, will fix those mismatches by performing whatever delete / copy operations will make the destination match the source exactly. – antred Jun 14 '17 at 14:24
  • OK, I can reproduce your problem, but only when `/R` is specified. Otherwise it will retry indefinitely. Perhaps `/R` is set to zero or to a small number in the registry on your machine? At any rate, that does seem like a bug in robocopy to me. (You are also correct about the `/MIR` switch and mismatched files. This condition typically indicates that something unexpected has happened, but it does not prevent robocopy from mirroring the directory trees.) – Harry Johnston Jun 14 '17 at 21:36
  • ... the most obvious workaround for the putative bug is to run the same robocopy command twice; if the first one succeeded, the second one will return zero. Of course that only works if neither the source and destination are changing while your script is running. – Harry Johnston Jun 14 '17 at 21:37
  • @HarryJohnston That solution is principally possible, but sadly quite time consuming. In many of our use cases, the mirroring takes 4 minutes even if the source and destination are already largely identical and we're running dozens of these operations each day (part of an automated test system). :-\ – antred Mar 26 '20 at 12:39
  • 1
    The workaround is not reliable. Robocopy may return exit code 0 even when there was an error. It happened to me with /R:0 and error 32 (0x00000020). You will have to parse the log file. See https://serverfault.com/questions/409644/how-to-detect-robocopys-failure-to-delete-from-source. I consider this a bug in Robocopy and have reported it here: https://github.com/MicrosoftDocs/windowsserverdocs.de-de/issues/49 – Marco Eckstein Apr 20 '21 at 23:24

0 Answers0