Thursday, July 26, 2012

Using Robocopy to backup My Documents

Having attempted to use robocopy.exe to make a backup of a users data files I came across the following behavior.

I was trying to be "pure" and use the command line and not just to use drag and drop using Windows Explorer. The theory here was not only that it should provide a more robust copy, i.e. I could restart the copy if it was interrupted, but also I could then incorporate the command into a backup script.

It became obvious that the file structure for Windows 7 was not as simple as it first might appear and I was concerned that all the iPad and iTunes files, plus others, were being copied as well as the contents of the directory that I wanted a copy of. The resulting copy reported 52G Bytes of data when the actual data that I wanted to copy was only 8G Bytes. The copy took 1.5 hours as opposed to a matter of minutes for the copy that I wanted.

Junction Points and the solution:

Like a lot of the replies you see to problems that you find on blogs and forums this is no exception. Many of the solutions posted had nothing to do with the original question. However, having read the solution (linked below) it made sense to what I was seeing.

The answer was to use the /XJ switch telling robocopy to ignore the Junctions or the directories that the Windows 7 file system includes behind the scenes.


Running the help for robocopy shows that the response detailing the answer to the problem is actually the case. I guess that I could have worked out the problem for myself.

The other thing that is confusing is that the answer on the Microsoft Windows 7 forum is that it is not easy to see who is replying to whom. The answers are there but a lot of what there is in the post is occluded. The original question was phrased in a way that an infinite loop was being seen, my problem and solution was not that but I guess that I could have been fooled into thinking that there was one.

In addition, there is another answer to what I was seeing in the Microsoft forum replies. A commenter was warning that there could be other problems if a robocopy command was used to change the target of a junction directory as there would be problems in the future. In my case the copy on the target drive ended up hidden as I guess that the permissions and/or the resulting junction confused Windows Explorer when the drive was viewed. Searching the drive for the copied files revealed that the files were there but could not be seen. I will have to re-format the target drive as the disc space is being used but I cannot see the files!

Links:
Folder permissions and other things found when using robocopy:

 In addition to the behaviour that I describe above you may also find that you will get "permission denied"  messages when you try and copy files and directories from the root of a drive. The cause of this is due to a similar to reason as the directories that are attempted to be copied in this instance are again Junction directories.

I covered this on my website in more detail and possibly made another post on this blog. I discussed the command syntax that you need to use to stop the errors due to these "forbidden" directories asking to be copied:

robocopy /mir k:\ \\Mybookworld\public\ /XD dirs $RECYCLE.BIN /XD dirs RECYCLER /XN /XO

In the command above the directories are excluded from the robocopy processing - I had not found a way to set the Windows permissions to allow the copying of these directories. However, I would suggest that you would not want to in any case as it would probably give you problems in the future.

1 comment:

Hanoi said...

robocopy folder structure permissions

Root only - but could see this