Vista Tutorial - robocopy stopping with unresolved files

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

On Thu, 23 Aug 2007 06:44:05 -0700, PeterBBailey wrote:

>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
--
No mail, please.

"PeterBBailey" <PeterBBailey@discussions.microsoft.com> wrote ...
> 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,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

"Andrew McLaren" wrote:

> "PeterBBailey" <PeterBBailey@discussions.microsoft.com> wrote ...
> > 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,
> --
> 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.