SYNCLOCAL dir goes into error mode.

SYNCLOCAL dir is going to error mode when it shouldn't.
It appears to only happen when files on the destination side
are required to be deleted in order to sync. I don't have
GETLASTERROR copied. How can I tell what's going on. I have
validated that the connection is valid and there does not
appear to be any idle time on the connection.

Here's the code:
DIM retry, number, 3

OnErrorGoTo Error_Handler_Label
now(timenow)
concatex(timenow, "::Set ErrorHandler to OnErrorGOTO", msg)
LogAddMessage ("INFO", msg)
Restart_Label:
// executes an exe that runs the NET command to map a drive to the share then runs the sync.
runandwait("d:\\apps\\247\\cabackupnet.exe", "", 0, process)
now(timenow)
concatex(timenow, "::Ran Command:\\apps\\247\\cabackupnet.exe" , msg)
LogAddMessage ("INFO", msg)
SyncLocalDir(BACKUPLOC, DEST, True, True, True, True )
now(timenow)
concatex(timenow, "::SyncLocalDir Completed Normally", msg)
LogAddMessage ("INFO", msg)

goto CONT

Error_Handler_Label:
// the following 4 lines are commented because the version 3.4.2 does not recognize getlasterror as a valid keyword
//getlasterror GLEMESSAGE
//now(timenow)
//concatex(timenow, "::SyncLocalDir returned an ERROR - ", GLEMESSAGE, " - Value of retry is - ", retry, msg)
//LogAddMessage ("ERROR", msg)
Subtract retry, 1, retry
wait(120)
If (retry, Restart_Label, END)

Please check it is not an issue with permissions.

You can find out in the sync.log file (on the computer running SYNCLOCALDIR) which file was processed last this way you can figure out which file caused the problem.

: SYNCLOCAL dir is going to error mode when it shouldn't.
: It appears to only happen when files on the destination side
: are required to be deleted in order to sync. I don't have
: GETLASTERROR copied. How can I tell what's going on. I have
: validated that the connection is valid and there does not
: appear to be any idle time on the connection.

: Here's the code: DIM retry, number, 3

: OnErrorGoTo Error_Handler_Label
: now(timenow)
: concatex(timenow, "::Set ErrorHandler to OnErrorGOTO", msg)
: LogAddMessage ("INFO", msg)
: Restart_Label: // executes an exe that runs the NET command to map a drive to
: the share then runs the sync.
: runandwait("d:\\apps\\247\\cabackupnet.exe", "", 0,
: process)
: now(timenow)
: concatex(timenow, "::Ran Command:\\apps\\247\\cabackupnet.exe" ,
: msg)
: LogAddMessage ("INFO", msg)
: SyncLocalDir(BACKUPLOC, DEST, True, True, True, True )
: now(timenow)
: concatex(timenow, "::SyncLocalDir Completed Normally", msg)
: LogAddMessage ("INFO", msg)

: goto CONT

: Error_Handler_Label: // the following 4 lines are commented because the
: version 3.4.2 does not recognize getlasterror as a valid keyword
: //getlasterror GLEMESSAGE
: //now(timenow)
: //concatex(timenow, "::SyncLocalDir returned an ERROR - ",
: GLEMESSAGE, " - Value of retry is - ", retry, msg)
: //LogAddMessage ("ERROR", msg)
: Subtract retry, 1, retry
: wait(120)
: If (retry, Restart_Label, END)

: Please check it is not an issue with permissions.

: You can find out in the sync.log file (on the computer running SYNCLOCALDIR)
: which file was processed last this way you can figure out which file
: caused the problem.

It lists

New Files:
==============================
File.log
file1.log

Deleted files:
==============================

That's it. That's what I was saying. When a delete is
required, it appears that it returns an error because
the SYNCLOCALDIR keyword drops to the error handler.

Who does the SYNCLOCALDIR attempt to log in as? The user
that it's running as??? If so, they have been updated.

If I install the files for GetLastError, will that give
more detail on what is causing SYNCLOCALDIR to go into
error mode?

Don't you already have an error in the job log stating why SYNCLOCALDIR failed?

You can use GetLastError but not simply allow the job to handle errors (set the job to not to ignore errors) and then rerun the job manually. You should get an error message displayed on the screen and also written to in the main job log file..

: It lists

: New Files: ==============================
: File.log
: file1.log

: Deleted files: ==============================

: That's it. That's what I was saying. When a delete is
: required, it appears that it returns an error because
: the SYNCLOCALDIR keyword drops to the error handler.

: Who does the SYNCLOCALDIR attempt to log in as? The user
: that it's running as??? If so, they have been updated.

: If I install the files for GetLastError, will that give
: more detail on what is causing SYNCLOCALDIR to go into
: error mode?