TCC 13 COPY: specified network name is no longer available.

[mdwyer]

I have a puzzling error which occurs with Take Command v13 using copy command. I do not think this is a TCC error, but thought I would ask in case there was an issue with v13 that I am not aware of.

Trying to COPY many directories using /UF switch from a new WD NAS to a W2008R2 server. It consistently fails at same directories (perhaps 2-4 failures per run) with the message: "The specified network name is no longer available" and then keeps going to the next directory. For example from one log:

"Y:\INTERNET\DANTZ\Retrospect 7.6\Retrospect\EN\Clients\Solaris\*.*"
[12/01/15 10:56:04][11492] There are no more files.
"Y:\INTERNET\DANTZ\Retrospect 7.6\Retrospect\EN\Clients\Windows\*.*"
[12/01/15 10:57:04][11492] The specified network name is no longer available.
[12/01/15 10:57:04][11492] There are no more files.
"Y:\INTERNET\DANTZ\Retrospect Client 7.6 - Windows\*.*"
[12/01/15 10:57:04][11492] There are no more files.

I have tried various network switches and cards and the error persists. Curious. Solarsoft monitor (running on a 3rd computer) show that there was never any loss of connectivity for both computers, altho that is a meaningless test perhaps since it only checks every 2 min.

 

[Alpengreis]

Have you tried with "normal" xcopy from the windows console? If the result is the same, then I would assume, it has nothing to do with TCC ...

 

[rconn]

I have a puzzling error which occurs with Take Command v13 using copy command. I do not think this is a TCC error, but thought I would ask in case there was an issue with v13 that I am not aware of.

This has to be a Windows issue -- TCC simply calls the Windows CopyFileEx API to do the file copy.

 

[mdwyer]

I will test (Copy process takes several hours, and stresses server, so not trivial to test). Unless I am mistaken, the copy and xcopy commands in CMD do not have a file compare switch (xcopy /u overwrites or so I thought)? It occurs to me that I can use ROBOCOPY though - I will test.

FWIW, this error occurs even when the routine is run after both directories are identical, so no actual copying is occurring - so not so sure what is up. I ran a disk scan on the NAS, but that came back clean. Old troubleshooting rule is consistent failure is software, not hardware, but I figured if it happened at same spot, maybe it was bad sector, but apparently not. Load on NAS is very light and disk latency is low. It is very puzzling to me.

 

[mdwyer]

RoboCopy worked well with zero failures, so I will simply use that instead. Fwiw, I used these switches in robocopy: ... /S /FFT /XO /ZB /R:2 /V /LOG:filename
From the end of the log:
Total Copied Skipped Mismatch FAILED Extras
Dirs : 56554 0 56554 0 0 0
Files : 1562200 4 1562196 0 0 1

 

[Alpengreis]

Well, Rex gave the answer. However: you said in your first posting /uf in your second /u ... you know that /uf and /u /f is not the same?