1

I am having an intermittent issue with ROBOCOPY copying files with an incorrect date.

I am using ROBOCOPY to copy backup files from a local folder to a remote fileshare as a part of having a remote backup solution. The script is scheduled through task manager to run daily. Here is pseudo code:

ROBOCOPY E:\LocalFolder \\RemoteServer\FileShare\Folder *.bak

Most of the files copy with the correct file date, hovever one or two files sometimes will have the date of 1/1/1980. This presents a major issue with managing the backups in the fileshare because the dates are crucial to its management.

What might causes this? What can be done to prevent this behavior?

user1944272
  • 209
  • 6
  • 15
  • What is the date stamp for those one or two files? – Bill_Stewart Jun 24 '14 at 15:39
  • "one or two files sometimes will have the date of 1/1/1980" - The original date stamp would have been 6/23/2014 for the previous day, however after being copied to the remote location it may take on a different date stamp value. If it does, that new value will always be 1/1/1980. – user1944272 Jun 25 '14 at 19:55
  • I am wondering whether the date on the source file might not be what you think it is, depending on how you're viewing it. – Bill_Stewart Jun 26 '14 at 14:12
  • The dates are how I stated. (6/23/2-14 on the original file and 1/1/1980 on the copied file) There is no mistaking it because there are only a few files being moved. The files and dates are viewed using File Manager. – user1944272 Jun 26 '14 at 20:47
  • As I said, the only thing I can suggest is that whatever metadata you're looking at in your file manager isn't the same as what robocopy is using. – Bill_Stewart Jun 26 '14 at 21:55
  • I'm not sure how ROBOCOPY could look at any other metadata. Additional info: The files that are being moved are only a day old. They are backup files created by SQL Server. So a backup of a particular database might one day be copied with its correct file date and the new file created the next day be copied over with a January 1st 1980 date and then the third day the new file is copied with the correct date. Given that SQL Server is very consistent with backup file cration and ROBOCOPY is a mature and reliable application could it possibly have anything to do with network connection issues? – user1944272 Jun 26 '14 at 22:41
  • Not saying that it's impossible, but it would be rather odd that a connectivity issue would present itself only with certain files. – Bill_Stewart Jun 27 '14 at 02:55

1 Answers1

1

I was having a similar issue. After some searching, I found reference to a behavior of Robocopy where it sets the modified date to 1/1/1980 until after a transfer is completed. [source]

What was really strange in my case was, if I watched the directory during the copy, I would see the file with the correct date appear, then AFTER it was complete the date would change to 1/1/1980. After some experimentation, I removed the /B switch I had been using and the dates seemed to be left alone.

Mattio
  • 2,014
  • 3
  • 24
  • 37