Late last year we went through a large storage transition - Netapp 7-mode to cDOT and I used a robocopy script to do some migration of CIFS shares.  Long story short, the log file from robocopy has several examples as follows:

2 \\x.x.x.x\etc etc\etc\etc

This makes it appear that 2 files were successfully copied into that folder, however the destination folder is empty.  CIFS share to CIFS share.

Has anyone ever seen this before?  No errors, no permissions issues (in theory?)  Is there any hope?  I've tried navigating to the share i powershell, also shows empty.

Let me know if you need any more info...

• Edited by Ryno2Fifty Wednesday, March 18, 2015 11:20 PM

Well, the actual content is a bit more complicated than copying a single folder and files, but here it is.



In this instance, is skipping 1.5mil files because they have been copied to the destination already.

I had to use the /M parameter, otherwise robocopy wouldn't perform properly and overwrite each file each time the script ran.  Again, we probably ran this 20 times in preparation for the storage transition - and then closing it off in DNS and running it a final time.

It's more or less random.  Within a folder, folder A and C will be fully populated while B and D will be empty.  With all the robocopy bugs I'm seeing, is it possible it didn't set the archive bit properly, therefore didn't copy files?

There is no trying again.  This is 5 months ago and one of our departments is just now noticing some empty folders...so it's not widespread.

• Edited by Ryno2Fifty Thursday, March 19, 2015 3:16 PM

So it appears my script should have worked as I intended with the /M option set.  In my testing:

Put a new file in folder 1, A is set.

Run Robocopy, file is copied to destination and A attribute is removed from source

Make change to source file, A is again set

Run Robocopy, file is copied to destination and A attribute is removed from source

So my question is - why would "A" not be set in the first place, causing the file to not get copied with /M?

We were using /M in the first place because Robocopy in Windows 8 appears to have a bug where it copies files that have not changed.  Therefore making my 2TB transfer impossible to do effectively.  Therefore /M being the (apparently incomplete) workaround.

Basically, I should have used an earlier version of Robocopy, no?  Most people seem to be pointing to the version from 2003.

Furthermore, as I stated in my first post, the log entry has 2 \\x.x.x.x\etc etc\etc\etc - what exactly does the 2 signify?  Surely it can't be that it has copied two files, since it copied nothing?  Is it just telling me how many files are there?

• Edited by Ryno2Fifty Monday, March 23, 2015 5:28 PM

Hi,

Archive bit used by backup programs to determine the files and folders that need to be backed up. Enabling the archive bit will ensure that the folder is backed up during the next incremental backup. Disabling the archive bit will prevent the folder from being backed up during the next incremental backup. The archive flag is turned on whe a file is created or changed. Then, when you use backup software the archive flag is turned off until until the file is changed again.

About "the log entry has 2 \\x.x.x.x\etc etc\etc\etc " you mentioned, please post the exact log screenshot for analysis.

Here is the screenshot of the entry in the log file (with the IP changed)



So what do the 1 and the 24 actually stand for?  Is it just telling me how many files are there or is it saying how many it transferred?

Hi,

Please post the exact screenshot. Didn't syntax the output same like mine?

It would tell you the total, copied and skipped etc entry.

I posted the exact screenshot of the totals earlier in the post.  This last screenshot is an exact screenshot of an individual entry.   I can't post the whole thing because its a couple terabytes worth of logs...I just want to know what the number means before the \\192.168.1.1...