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

Hi,

Let us know the exact log file content. Based on my test, it would show as below when destination directory empty:

Here, we could see, it only copy one directory successfully and skip (not copy) that 3 files.

I would like to suggest check it and remove parameter "/M" to have a try.

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 16 hours 4 minutes ago

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

Hi,

You just use the following command to check if the skipped files' attribute to see if it's Archive.

attrib [[Drive:][Path] FileName] (One example as below)

The first output without A means no Archive attribute.

After added, the second output with A means it's attribute is Archive.

If you specify the parameter /M, it would copy only files for which the Archive attribute is set, and resets the Archive attribute. And you have specified parameter /copyall, it would not only copy the file you seen but also the file properties.

For more information, please read this guideline:

Robocopy

https://technet.microsoft.com/en-in/library/cc733145.aspx

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 13 hours 51 minutes ago