4

Related: Scheduled Robocopy task fails with 0x10 error

I'm using robocopy as part of a server backup script. It fetches the files to this workstation (Windows 7, upgraded from Vista - that caused some quirks before), and then copies them to a server in LAN (Windows Server 2000).

robocopy H:\folder \\SERVER\drive\folder /MIR /LOG:H:\backup.log /TBD /TEE

When this task runs in scheduled tasks, usually the network folder has not been accessed yet by the computer since startup. As such, it usually ends up failing:

-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows                              
-------------------------------------------------------------------------------

  Started : Fri Jul 12 16:16:03 2013

2013/07/12 16:16:03 ERROR 3 (0x00000003) Getting File System Type of Destination \\SERVER\drive\folder
The system cannot find the path specified.


   Source : H:\folder
     Dest - \\SERVER\drive\folder

    Files : *.*

  Options : *.* /TBD /TEE /S /E /COPY:DAT /PURGE /MIR /R:1000000 /W:30 

------------------------------------------------------------------------------

2013/07/12 16:16:03 ERROR 3 (0x00000003) Creating Destination Directory \\SERVER\drive\folder
The system cannot find the path specified.

As you can see, I tried using /TBD switch to wait for network share names to be defined. It did not help. However, forcing the scheduled task to run manually later successfully updates all the files. Though I didn't access the server backup folder during that time, I did access a different share on the server.

What should I do? Add a retry in the batch script? Or use a different program to make sure the network path is available before continuing?

Community
  • 1
Sašo
  • 1,464
  • 2
  • 9
  • 13
  • Check your permissions. Your "manual" run , probably runs as admin. – user Jul 12 '13 at 17:01
  • The user account is used in both cases – Sašo Jul 12 '13 at 17:05
  • Start the script with a "net use z: \\server\drive\folder" and end it with a "net use z: /d" and see if that helps. – Katherine Villyard Jul 12 '13 at 22:11
  • Attempted that with identical conditions and `net use`, same issue. Second run worked fine. I recall having to deal this issue in the past when using Synctoy. Tried using `dir` to attempt to list directory contents and thus connect, but it never worked correctly. – Sašo Jul 14 '13 at 14:20
  • @user Turns out that the opposite was the case and I never noticed. I had "Run with highest privileges" checked and the automatic run ran as administrator while manual runs ran as User. Changing that also fixed missing folder, so I guess /TBD switch started working. Put it up as an answer and I'll accept it. – Sašo Jul 21 '13 at 17:50

2 Answers2

3

Check your permissions.

Your "manual" run , probably runs as admin , or the other way around.

user
  • 1,408
  • 8
  • 10
  • Though not the exact issue, it narrowed down the problem. After using user account (and not running at highest privileges), the folder is found without problem (or at least the /TBD works) – Sašo Jul 26 '13 at 20:47
0

As far as I can tell, in this case, the problem is the interpretation of the exit codes that Robo copy sends to Scheduled task when it finishes. Scheduled task does not like anything other than 0, but RoboCopy has exit codes ranging from 0 to 16. The reason it works for you second time is that RoboCopy returns code 0 (no changes found to files) and scheduled task "interprets" it as a correct execution (code 0). I would categorize this as another Microsoft bug.

shifa
  • 1