Where are my files, ROBOCOPY?

Every Wintel administrator is familiar with the Robocopy utility. Since the days of Windows NT4, it has been included in the Resource Kit, and since Windows Vista it has been included in the operating system.
Why do you need Robocopy? In order to copy files. Lots of files. We mainly use it to migrate file servers or backups.
There are many interesting options for migrating file servers, for example, using DFS-R. But nothing is easier and safer to run.

robocopy \\SERV\D$ F:\ /e /copyall /zb /mt:8 /r:1 /W:5 /V /TS /FP /ETA /TEE /LOG:c:\temp\robocopy.txt


In the final, you can close the user access to the resource and create an incremental copy by adding the / MIR key.
But is Robocopy so good ? Is it good enough to entrust the migration of the most important files to it?

')
One fine Saturday afternoon, I migrated a file server. There were no employees at work. The first copy was made yesterday, it remained only to make an increment and update the links in DFS.
I launched Robocopy, looked at the log, and for reinsurance, before switching, I decided to see how many files and folders in the source and destination file resource. The numbers did not converge. Suddenly.



But why? I saw this result for the first time. Did I do something wrong? Someone from the staff still changed the files while incremental copying was going on? Key / MIR failed? Any files missing? Empty? With Access Denied? Damaged?

Well, disable network access and copy files again. Does not converge! We try without / MIR. The same result.
I was at a loss. For fifteen years, I was 100% trusted by Robocopy, and today, for the first time, it crashed. Some files are simply not in the destination! It is just impossible to believe it.

Let's count the files differently. Download the FileList utility and list the files in the source and destination folders. And here the number of files coincided. Amazing.

And what if it's not Robocopy? What if Windows Explorer counts wrong? Maybe in Windows Server 2008 R2 bad Explorer, and in Windows Server 2012 R2 good? I opened the local and target folder properties on the source Windows Server 2008 R2 server. The number of files did not match. Hopefully, everything is fixed in Windows Server 2012 R2. Open the folder properties on the new server ... And ...



Not only the number of files in the source and destination folders did not match. The number of files was different from those shot on Windows Server 2008 R2. Black street magic.

And at that moment (finally) an epiphany fell upon me. It's not about Robocopy, and not about versions of Explorer. Just Explorer can not (!) Count, and does not consider files and folders with names longer than 260 characters.

On the source server, the files were located along the path “F: \ Office1”. On the new - "U: \ SharedFiles \ Office1".
Just because of the “SharedFiles” subfolder, the names of some files and folders have become longer than 255 characters. For Robocopy, it’s easy to copy them. FileList easily calculated them. And only Explorer missed such files when counting.

By making subst N: U: \ SharedFiles and counting the number of files in F: \ Office1 on the source server and N: \ Office1 on the target, the number of files coincided.

@ # $ !!!

Robocopy can be trusted.

UPD : As correctly corrected in the comments, yet not 255, but 260 characters .
256 - directly file name "file.txt"
3 - "C: \"
1 - invisible null at the end
Thank!