robocopy stopping with unresolved files

G

Guest

I'm trying to run robocopy from my C: drive to a second drive, the F: drive.

I'm doing this:

robocopy c:\users\pb4072.intdom f:\users\pb4072.intdom /e /xa:sh /b /xo

After a couple of minutes, I'm getting this:

....
The name of the file cannot be resolved by the system.
Waiting 30 seconds...

Does anybody know what's going on here? Is there a switch I can use to
bypass these kinds of problems?

Thanks,
Peter
 
H

Hans-Georg Michna

I'm trying to run robocopy from my C: drive to a second drive, the F: drive.

I'm doing this:

robocopy c:\users\pb4072.intdom f:\users\pb4072.intdom /e /xa:sh /b /xo

After a couple of minutes, I'm getting this:

...
The name of the file cannot be resolved by the system.
Waiting 30 seconds...

Does anybody know what's going on here? Is there a switch I can use to
bypass these kinds of problems?

Peter,

read the f. manual. The /R: switch determins the number of
attempted repetitions.

Hans-Georg
 
A

Andrew McLaren

PeterBBailey said:
I'm trying to run robocopy from my C: drive to a second drive, the F:
drive.
I'm doing this:
robocopy c:\users\pb4072.intdom f:\users\pb4072.intdom /e /xa:sh /b /xo
After a couple of minutes, I'm getting this:
The name of the file cannot be resolved by the system.
Waiting 30 seconds...

Does anybody know what's going on here? Is there a switch I can use to
bypass these kinds of problems?

Hi Peter,

This is a standard Windows error, defined in Winerror.h:

ERROR_CANT_RESOLVE_FILENAME
# The name of the file cannot be resolved by the system.

Robocopy will just be reporting an error which percolating up from the Win32
File I/O calls. Why it's happening, I dunno - one possible cause is when you
have recursive links, which result in path names greater than MAX_PATH (for
most Win32 functions, 260 characters) - or else, just very long path names.
The NT kernel in Vista can handle pathnames up to 32K chars in length; but
for compatibility reasons, many Win32 APIs clagg out at MAX_PATH.

To get a perspective on what's happening, you can turn on logging for
robocopy:

C:\>robocopy c:\users\pb4072.intdom f:\users\pb4072.intdom /e /xa:sh /b
/xo /v /log:mylog.txt

After the error, use the log to identify the filenames causing problems.

Robocopy is, well, "Robust Copy" and it will keep ferociously trying to copy
files in the face of errors - by default, for one million retries on each
file. To make robocopy continue copying in the face of these errors, you
would need to turn down, or off, the retry limit:

C:\>robocopy c:\users\pb4072.intdom f:\users\pb4072.intdom /e /xa:sh /b
/xo /v /log:mylog.txt /r:5

The "/r:5" tells Robopy to retry 5 times, then give up and move on to the
next file.

Hope it helps,
 
G

Guest

Andrew McLaren said:
Hi Peter,

This is a standard Windows error, defined in Winerror.h:

ERROR_CANT_RESOLVE_FILENAME
# The name of the file cannot be resolved by the system.

Robocopy will just be reporting an error which percolating up from the Win32
File I/O calls. Why it's happening, I dunno - one possible cause is when you
have recursive links, which result in path names greater than MAX_PATH (for
most Win32 functions, 260 characters) - or else, just very long path names.
The NT kernel in Vista can handle pathnames up to 32K chars in length; but
for compatibility reasons, many Win32 APIs clagg out at MAX_PATH.

To get a perspective on what's happening, you can turn on logging for
robocopy:

C:\>robocopy c:\users\pb4072.intdom f:\users\pb4072.intdom /e /xa:sh /b
/xo /v /log:mylog.txt

After the error, use the log to identify the filenames causing problems.

Robocopy is, well, "Robust Copy" and it will keep ferociously trying to copy
files in the face of errors - by default, for one million retries on each
file. To make robocopy continue copying in the face of these errors, you
would need to turn down, or off, the retry limit:

C:\>robocopy c:\users\pb4072.intdom f:\users\pb4072.intdom /e /xa:sh /b
/xo /v /log:mylog.txt /r:5

The "/r:5" tells Robopy to retry 5 times, then give up and move on to the
next file.

Hope it helps,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

Thank you. It's that /r:5 there at the end of your informative text that lit me up. I think that's exactly what I need. I've been putting in a bunch of exception wildcard extensions, but, that kind of defeats the purpose. So, thanks again.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top