Robocopy major issue

I am working on a script with Robocopy XP026 and have a major issue with the
Return Code since it always return 0 even when there is a fatal error...
Does someone know a workaround for this major problem on Windows XP?

Thanks!

Robocopy major issue

I have read similar reports in other posts (including your first post on the
same subject). While I haven't been able to confirm (or otherwise) your
observation, I would do this:
- Check if the problem occurs on several machines.
- If it does, monitor the log generated by robocopy, or
- Use the previous version of robocopy.

Robocopy version XP010 doesn't have this issue on the same computer but then I

Robocopy version XP010 doesn't have this issue on the same computer but then
I would need to check the version of Robocopy each time the script is
installed on an other computer, not even only at installation but each time
it run since it could be updated after installation...
Some people may also need the XP026 version for it's new features or because
of other issues in XP010 that were addressed in version XP026 so I don't
want to break other scripts for having mine to work...

Robocopy is not subject to automatic updates.

Robocopy is not subject to automatic updates.

You did not say if the problem is specific to one PC or if it can be readily
reproduced on any PC. If so, how?

You are right about Robocopy not been subject to automatic updates but since

You are right about Robocopy not been subject to automatic updates but since
my script would update it, some other script could do the same and update it
to version XP026... I know that at least Robocopy GUI would do this, it
would install version XP026...

The problem is not specific to my computer, it do the same on any computer
and may be reproduced very easily with a small script like the following
one:

@Echo off
RoboCopy C:\ Z:\
Echo.
Echo ------------------------------------------------------------------------------
Echo.
Echo ErrorLevel = %ErrorLevel%


The output of this script with XP026 is:

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

Started : Fri Oct 24 15:58:56 2008

2008/10/24 15:58:56 ERROR 3 (0x00000003) Getting File System Type of
Destination
Z:\
The system cannot find the path specified.

Source : C:\
Dest - Z:\

Files : *.*

Options : *.* /COPY:DAT /R:1000000 /W:30

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

2008/10/24 15:58:56 ERROR 3 (0x00000003) Creating Destination Directory Z:\
The system cannot find the path specified.

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

ErrorLevel = 0


This is a fatal error so ErrorLevel should return a value of 16

I don't have a copy of Robocopy XP26 and I was unable to find a download

I don't have a copy of Robocopy XP26 and I was unable to find a download
location, hence I'm unable to duplicate your test. As I said before, you
could walk around the problem by detecting error conditions from the log
file like so:
@Echo off
RoboCopy C:\ Z:\ 1>c:\robocopy.log 2>&1
type c:\robocopy.log | find /i "Error" | find /i "0x" && echo Robocopy
reported an error.

It come with Robocopy GUI that can be downloaded from at this

It come with Robocopy GUI that can be downloaded from Microsoft at this
address:
http://download.microsoft.com/download/f/d/0/fd05def7-68a1-4f71-8546-25c359cc0842/UtilitySpotlight2006_11.exe

I need to run Robocopy in batch so it would add a bit too much overhead to
the process to redirect the output to a file for analysis...

Thanks for the link.

Thanks for the link.

I was able to duplicate the problem you report: Robocopy XP26 does not
appear to set the correct ErrorLevel. You therefore have to chose one of the
options I suggested before. By the way, I do not agree with your remark
about "too much overhead". I suggest you time the process, both with and
without redirection and error sensing. I'm sure you'll find that the
difference is negligible. Most of the elapsed time will be consumed by the
copy process itself.

Robocopy major issue

Simply knowing that this may happen should suggest a few ideas.

First, how do you know a fatal error has occurred? If you can figure it out
from, for example, the log file, then it might be possible for your script
to find out the same way.

Second, what kinds of fatal errors are you experiencing? There might be ways
of pre-determining the circumstances that tend to cause them.

/Al

Robocopy major issue

No problem, I do this kind of thing all the time. Install the robocopy you
need unconditionally with the script. Then make sure the script only runs
the robocopy sitting in the same folder by referencing it this way:

/Al

Yes I'm doing it that way on my Windows XP machine and didn't even need to

Yes I'm doing it that way on my Windows XP machine and didn't even need to
rename it since it's in the same directory as the script it get priority
over the other version in the System32 directory. I don't think I can freely
distribute it with my script thought, I wanted people to download there own
copy from Microsoft but I don't have control over where it's installed
then...

Robocopy major issue

Since you have no control over how your users actually *run* your script, it
may not be safe to assume that the current directory is the one in which
your script and its support files are located. That is why I suggested
calling it this way:


as "%~dp0" _is_ the folder where the script is located.


That would depend. I have not read the EULA lately, so I do not know what it
may say about distribution - I'd recommend you check there to see if it
specifically mentions re-distribution as either allowed or disallowed.

But it may also depend on your environment. If the users to whom you are
distributing your script are limited to staff of your company and if the
computers involved are all owned by the company, then you are not
distributing the software beyond where you are licensed to.


The installation script that installs your script could advise the users of
this dependency. You may have no control over where they might install it
(and cannot even be sure that they will), but if they do not follow your
installation instructions, then it is their problem if it fails.

Alternately, yes, you could code your script to search for the first copy of
robocopy that is the required version and either use that copy, or advise
the user that they need to download it.


/Al

Robocopy major issue

nce
it
r
----------
------
------
-----
-----
t
t
ach
so
ith
on
)

Need to make sure your script is mapping those drives.  Just be cause
that user's profile has a drive mapping script, doesn't mean it will
be run when the task scheduler runs it.  :)

I beat my head against this for a few days too.

Robocopy major issue

Need to make sure your script is mapping those drives.  Just be cause
that user's profile has a drive mapping script, doesn't mean it will
be run when the task scheduler runs it.  :)

I beat my head against this for a few days too.

=============

The OP had no problem running robocopy.exe. His problem related to the
incorrect %Errorlevel% generated by robocopy.exe..

I downloaded the RoboCopy GUI from the same link, however, I do not see the

I downloaded the RoboCopy GUI from the same link, however, I do not see the
XP026 version anywhere in the package.  Running RoboCopy from the command
line or with the GUI still uses the XP010 version.  This is very frustrating,
I've wasted over an hour trying to find this latest version so I can use the
/DCOPY:T switch.

I have resolved my own issue.

I have resolved my own issue.  It appears the RoboCopy GUI install places the
XP026 version in C:\Windows\System32 folder.  Since the W2k3 Resource Kit
Tools version (XP010) was referenced first in my PATH variable, it was still
being used.  I simply renamed the older copy of robocopy.exe and now the new
version is available.