Robocopy PURGE (or MIR) option is not deleting files in use and not reporting an error

0

In TFS release, there's an a release step called "Windows Machine File Copy". Under the covers it uses robocopy to copy the files from the source to the destination.

Here are the options it uses:

*.* /S /E /DCOPY:DA /COPY:DAT /PURGE /MIR /MT:8 /R:1000000 /W:30 

The release step prior to this is stopping a windows service, which works fine. There's even a 3 second delay at the end of the script. I think we've coded this service to finish all communications during a shutdown, so it takes longer than 3 seconds to finish. When this happens, some of the files are in use. Robocopy seems to be working fine for files that it copies, but the *EXTRA files is a different story, they are not deleted and not retried - just left there. Furthermore, the report at the end shows no errors, even though there are plenty of errors in the log.

2017-05-08T15:37:07.7528791Z -------------------------------------------------------------------------------
2017-05-08T15:37:07.7528791Z    ROBOCOPY     ::     Robust File Copy for Windows                              
2017-05-08T15:37:07.7528791Z -------------------------------------------------------------------------------
2017-05-08T15:37:07.8622643Z   Started : Monday, May 8, 2017 10:37:07 AM
2017-05-08T15:37:07.8622643Z    Source : F:\Source
2017-05-08T15:37:07.8622643Z      Dest : \\myserver\E$\destination\
2017-05-08T15:37:07.8622643Z     Files : *.*
2017-05-08T15:37:07.8622643Z        
2017-05-08T15:37:07.8622643Z   Options : *.* /S /E /DCOPY:DA /COPY:DAT /PURGE /MIR /MT:8 /R:1000000 /W:30 
2017-05-08T15:37:07.8622643Z ------------------------------------------------------------------------------
2017-05-08T15:37:09.0185873Z      *EXTRA File         269824    \\myserver\E$\epay\destination\HtmlAgilityPack.pdb
2017-05-08T15:37:09.5186163Z      *EXTRA File         321024    \\myserver\E$\destination\Common.pdb
2017-05-08T15:37:09.5186163Z 2017/05/08 10:37:09 ERROR 5 (0x00000005) Deleting Extra File \\myserver\E$\destination\Common.pdb
2017-05-08T15:37:09.5186163Z Access is denied.

You can clearly see the error, but the report does not show any errors and the release step succeeds causing potential issues in our release.

2017-05-08T15:37:46.8492207Z                Total    Copied   Skipped  Mismatch    FAILED    Extras 
2017-05-08T15:37:46.8492207Z     Dirs :         1         1         0         0         0         0 
2017-05-08T15:37:46.8492207Z    Files :        54        54         0         0         0        49 
2017-05-08T15:37:46.8492207Z    Bytes :    8.45 m    8.45 m         0         0         0    8.55 m 
2017-05-08T15:37:46.8492207Z    Times :   0:01:49   0:00:25                       0:00:00   0:00:13

As I mentioned, it doesn't attempt to retry the failed deletes, but it will retry to copy files that failed due to the same error as I've seen evidence in the logs.

Is there a way to tell robocopy to retry failed deletes and report errors if any files could not be removed? I've read all the documentation but couldn't find anything related to this issue or a possible work-around. Any ideas?

tfs
robocopy
asked on Stack Overflow May 8, 2017 by Chris Gessler

2 Answers

1

Have you tried using the error codes?

https://ss64.com/nt/robocopy-exit.html

Anything below %ERRORLEVEL% 8 seems like the level you want.

Copy paste from the robocopy-exit.html:

ROBOCOPY \\Server1\reports \\Server2\backup *.*
IF %ERRORLEVEL% LSS 8 goto finish

Echo Something failed & goto :eof

:finish
Echo All done, no fatal errors.
answered on Stack Overflow May 22, 2017 by arkod
0

The "Extra" files are the files in the destination folder but not in the source folder. According to this, I'm wondering that the "Common.pdb" is generated by the any service/application on your release server rather then your build/release which means that you may not have permission to delete this file. And the robocopy Error 0x00000005 is also usually caused by permission issue. So you need to go to the path of "Common.pdb" file to check the permission and try to delete it manually with the account you configured in Windows Machine File Copy task.

answered on Stack Overflow May 12, 2017 by Eddie Chen - MSFT

User contributions licensed under CC BY-SA 3.0