We experience problems when users create folder structures that exceed the 256-character limitation that Windows applications enforce. When we performed a recent migration, Robocopy produced a lot of errors concerning long pathnames. When I tried Robocopy XP010, I experienced no long-pathname errors. How does Robocopy XP010 handle long pathnames?
By default, Robocopy XP010 can copy the filenames and folder names that exceed the 256-character limit—to a theoretical 32,000 characters—without logging any errors. If you want to force Robocopy to produce such errors so that you can see where your long-pathname problems originate, use the /256 switch. This switch causes Robocopy to produce errors that are similar to those with which you're familiar. Remember, though, that some user applications might not be able to access paths whose names exceed the 256-character length, and long pathnames might complicate verification of a successful copy.
If you plan to use the resource kit's Diruse directory-size comparison tool or another utility to verify your copy success, the tool might have long-pathname limitations that give you different results between the source and destination. Suppose you have a share named \FileServer1\ShareA that contains only one file. This 10MB file, called LongFile.txt, is many folders deep in the file structure and has a 253-character path length. You use Robocopy to copy this file to another server, thereby adding one more level to the path: \FileServer2\ShareB\OldShareA. Without realizing it, you've increased the path length by 10 characters. Robocopy will copy the file successfully (unless you use the /256 option to force an error).
If you then use the Diruse tool to compare the results, the 10MB LongFile.txt file isn't visible to the Diruse utility on the new shared location because the pathname now exceeds the 256-character limit. Instead, the comparison shows that you're missing 10MB of data and one file.
Imagine if you had thousands of files that were near the threshold and a small change took hundreds of them over the 256-character limit. Even though everything is fine, you would doubt the integrity of your copy task. At times like this, the Robocopy log file is an invaluable indicator of copy successes and failures.
I'm searching some large Robocopy log files for errors, but the size of the logs is complicating my efforts. What should I be looking for in the logs, and what causes most failures?
The report summary section at the bottom of the Robocopy log file shows failures, but I also typically run a search on the words Exceeded and ERROR in the log files to see where the copy failed. The majority of Robocopy failures I see are the result of insufficient permissions on the source or destination location. If you're copying security settings, ensure that the account you're using has Full control on the destination server.
We're migrating several hundred shares from one server to another. Can we use a script to run Robocopy on all the shares without writing individual Robocopy scripts for each share?
Here are a couple of options for you. If the servers are identical in terms of storage and have the same drive-letter configuration and drive contents, you could copy from the root of each drive instead of from the shares. The downside of this approach is that your log files would be organized by drive and not by shares.
Alternatively, you could use a script that takes input or share names from a list and runs Robocopy against each share. The RoboCopyMigration.bat script, which Web Listing 1 (http://www.windowsitpro.com/windowsscripting, Instant Doc ID 44324) provides, modifies the command-prompt window title so that you can view copy progress at a glance and see which share you're on in the share list. RoboCopyMigration.bat creates logfile names in a format that combines the share name and a timestamp of when the copy run started. Note the use of the new Robocopy /TEE switch, which sends output to both the log file and the console.
I don't fully trust the log files on copy utilities. I want to independently verify that correspondence is 100 percent accurate between the source and destination locations after my final copy is finished. What's the easiest way to do that?
You're wise to use an independent tool to verify your copy operations. You can use several GUI tools—such as TreeSize (http://www.jam-software.com/freeware)—to perform comparisons. If you prefer to stick with a scripted approach, the resource kit's Diruse tool works well. I like to check on the number of files and the total amount of data in the source and destination folders. If these numbers agree, I feel confident in the success of the copy job. The MigrationCompare.bat script in Web Listing 2 creates an output file that gives you file-count and data-size information for each share in your share list.
I've introduced you to Robocopy XP010 and a few of its powerful new switch options. I also covered some tips for performing migrations to NAS devices, using Robocopy for replicating over slow links, and verifying that your copy operations and share creations are accurate. Armed with these scripts, strategies, and techniques, you should be ready to take on any migration tasks from a few hundred megabytes to several terabytes.