5

I've got a robocopy script running that has been only working sporadically in the past few weeks.

The Problem

  • In the source directory, I'm receiving files twice a day. This script has worked for years flawlessly, but since ~December, two out of three times the script runs it ignores the files.

The Script

The goal: Copying files within a naming scheme *Identifier1* to a UNC path, then process them with another application which moves them.

set sourcefile=D:\some\local\path\here\
set destination=\\someip\some\path\
mkdir %destination%
robocopy %sourcefile% %destination% *Identifier1* /V /R:5 /W:10 >> %Logfile%

wait 60  
anotherapplication.exe

The Environment

  • Fully patched Windows Server 2012R2
  • Legacy batch script, not a powershell script
  • I trigger the script via task scheduler with elevated rights
  • User executing is a domain user with local administrative rights
  • I have to use the *Identifier*in the script. I receive two files, one being named $Timestamp_Identifier1.csv and the other $Timestamp_Identifier2.csv. I only need to copy one of them.

What I've tried

  • checked both file and directories permissions - the user that is running the script definitely has r/w rights. Copying manually works perfectly fine when remoting in with his credentials.
  • Enabled the /V switch to get more output. Unfortunately, robocopy doesn't even mention the files it is ignoring in the log.
  • Enabled the /R:5 and /W:10 switches to make sure it's not a load issue
  • Tried to let robocopy copy to a local directory first, which results in the same behaviour of "working sometimes". It's the same files that get ignored if I copy both to a local and a UNC path in the same batch.

Things worth noting

  • Besides the timestamp, the files always have the same naming scheme
  • There is no visible difference between files that get copied and files that don't. This includes their name and file permissions.
  • The files are created in the source directory by WinSCP after downloading from a webdav-service. Log says nothing unusual.
  • the anotherapplication.exe that I run within the same script picks the files up just fine and is indeed capable of moving them.

Any ideas or hints? As always, thanks a lot.

6
  • The file does not change. There source folder stays empty until WinSCP retrieves a new file and places it in the folder. Afterwards, a script gets triggered that tells robocopy to copy the file to the UNC path. The anotherapplication.exe moves the file after processing it. I've added /FFT, thanks for this hint.
    – Patrick R.
    Commented Jan 30, 2017 at 14:43
  • Questions: (1) Is the destination a network share? (2) What are the file-system types of source & destination? (3) Did you try to turn off all firewalls and antivirus? To try: The /zb flag.
    – harrymc
    Commented Jan 30, 2017 at 14:53
  • (1) As pointed out above, it is an UNC path. However, copying to local storage yields the exact same results: In a run where it get's copied to to local path, it also get's copied to the UNC path. If it fails. both fail. (2) NTFS. Source an destination servers are 2012r2. (3) There is no additional client antivirus present. I did not turn of the firewall, might try that if I get any more desperate. Will try the flag soon, I'll wait for the zzt flags results first.
    – Patrick R.
    Commented Jan 30, 2017 at 15:27
  • That's correct. I've even placed a wait of up to five minutes before launching the following job. I feel like launching them in the same script does a better job of making sure they don't interfere with each other than splitting it up to different scripts.
    – Patrick R.
    Commented Jan 30, 2017 at 19:30
  • Another suggestion: Use /LOG+: to create the log instead, try running Robocopy in FOR loop with /L and /X flags for log, and check the log to see of there is any pattern to when it does not list the files for copying. This is very similar to comment from @Walmart but with Robocopy. Commented Jan 31, 2017 at 16:07

1 Answer 1

3
+100

Robocopy ignoring files sporadically. Copying files within a naming scheme Identifier1 to a UNC path

You could try to add the /FFT switch with Robocopy:

robocopy /FFT %sourcefile% %destination% *Identifier1* /V /R:5 /W:10 >> %Logfile%

Robocopy Switch

/FFT : Assume FAT File Times (2-second date/time granularity).

Better Description

/FFT uses fat file timing instead of NTFS. This means the granularity is a > bit less precise. For across-network share operations this seems to be much more reliable - just don't rely on the file timings to be completely precise to the second.


Another Example

I've used a similar syntax as listed below in the past for a file server migration of many hundreds of gigs of data using UNC paths without any issue or errors I couldn't resolve.

Consider using the IF NOT EXIST "%destination%" mkdir "%destination%" to only make the directory is it does not exist. Also consider doing a recursive DIR /S "%sourcefile%\*Identifier1*" >> %LogFile% to put the detail to the log to show the full path and file name of those that match the naming convention. This way you can see if the file shows in that command in the expected location before the Robocopy even begins as another level of confirming a file exists.

/ZB :: use restartable mode; if access denied use Backup mode.

IF NOT EXIST "%destination%" mkdir "%destination%"
DIR /S "%sourcefile%\*Identifier1*" >> %LogFile%
robocopy /FFT %sourcefile% %destination% *Identifier1* /ZB /SEC /COPYALL /SECFIX /R:5 /W:5 /LOG+:%LogFile% /V

Additional

  1. You might also consider testing the /IS, /M, and /A switches with Robocopy.
  2. You could potentially use XCOPY with the /Y and /F switch to get full logging with that method in a simple FOR loop which seems it'd do exactly what you need as well

    FOR %%A IN ("%sourcefile%\*Identifier1*") DO XCOPY /Y /F "%%~F" "%destination%\">> %Logfile%
    
2
  • It has failed again yesterday, so I added the /IS switch. I'll keep waiting, but if no one posts another answer that immediately explains and solves my problem, I'll award the bounty to you - the situation has at least become better.
    – Patrick R.
    Commented Feb 2, 2017 at 16:02
  • Thanks for your brilliant help so far. I've picked up your idea to only recreate the directory if it's not existing yet and will keep experimenting with the parameters. Since 9 out of 10 copy jobs have been working now, I'll just go ahead and award your bounty.
    – Patrick R.
    Commented Feb 3, 2017 at 9:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .