Windows 7 infinite loop while using Robocopy

Question

.  I recently was migrating data from my laptop (Win7-x64) to a new all-in-one (Win7-x86), and discovered something odd.  When Robo got to “Application Data” – which is just a redirection – it started copying the files, and then got stuck in a loop.  Inside “Application Data” was another “Application Data” with all of the pertinent files and folders.  Inside that, another “Application Data” with everything, on and on until the file system couldn’t handle the depth level.  Well, it allowed it to be created, but turned to jell-o when I tried to delete it.

Answer 1

Short answer: If you're using Robocopy, simply using the /XJ switch will avoid this problem.

Long answer:

This recursive file structure is indeed caused by the implementation of junction points in the NTFS file structure by Microsoft. Essentially, some "folders" are not actual folders at all, but junction or reparse points, which essentially reroute a directory name to another directory. This is much like mapping a drive letter to a directory or another drive, and the Windows system is designed to handle this NTFS structure situation behind the scenes.

In Vista and 7, Microsoft decided to standardize some of the typical Windows settings for users, documents, etc., which had varied over time. To maintain backward compatibility, the old standards were also retained BUT WITH JUNCTIONS REPARSING THEM TO REDIRECT INQUIRIES INTO THE NEW ACTUAL DIRECTORIES. Most programs work right through these junctions without even noticing. For example, C:\Documents and Settings points to C:\Users. Even though the former directory does not actually exist, it APPEARS to have the files and directories under the latter, and a change in the contents of either directory will be reflected in the other, since they are in fact, a single directory.

The difficulty comes from certain Reparse Points which essentially redirect to a parent directory. This causes a recursive cascade for unwary programs or users who are unaware of the proper handling of the junctions (even though the junctions are designed to be transparent to software looking for either directory). The usual "subdirectory explosion" situation comes from the fact that the \Documents and Settings$USER$\Application Data folder (consistent with XP convention) is a junction point in Vista to \Users$USER$\AppData\Roaming, which in turn can contain the Application Data junction as a subdirectory...

Under normal Windows permissions, the junctions and their directories are inaccessible and hidden. If permissions are changed or programs working outside Windows are not prepared to encounter these junctions, duplication and recursion is destined to occur. For those using powerful low-level command interfaces such as Repair Console, it is best to check the capabilities and switches on the commands by using the /? help switch (for example, Robocopy /?, xcopy /?, rd /?, etc.). If you are not sure what you are doing, be sure to backup ahead of time with a reliable Windows program, with proper use of Restore Points.

Another useful discussion is here: http://www.vistax64.com/vista-general/58035-nested-application-data-directory.html

Answer 2

I had the same problem with Cobian Backup after I foolishly messed with the permissions on my C: drive. Fortunately I had another laptop here with Window 7 and I was able to recreate the original permissions. Once I did that, the backup program worked normally. It creates a single, empty Application Data folder which is fine.

• To change the permissions right click on the Application Data link and select Properties.
• Select the Security tab
• Click Advanced
• Select the Owner Tab
• Change the Owner to your current user (presuming you are an administrator)

 - Changing the owner deleted all existing permissions on the link

• Set up the permissions as shown below

 - Do only the ones for Full Control first then...

• Change the Owner to SYSTEM
• Then add the Deny rule for Everyone
• It may not matter that you do this last but this order worked fine for me and prevented the common problem of blocking yourself before change the Ownerr permissions to SYSTEM

Permissions that work properly

Owner: SYSTEM

Type	Name	Permission	Inherited From	Apply To
Deny	Everyone	List Folder/Read Data	not inherited	This folder only
Allow	SYSTEM	Full Control	[path of parent folder C:\Users[Username]]	This folder, subfolders and files
Allow	Administrators	Full Control	[path of parent folder C:\Users[Username]]	This folder, subfolders and files
Allow	[whatever your current user name is]	Full Control	[path of parent folder C:\Users[Username]]	This folder, subfolders and files

***EDIT: I see that an earlier post from Ronnie Vernon contains this same basic info. I missed the details on changing the permissions when I first read through all the posts.

Answer 3

I had the same thing happen. I used the /purge function in robocopy to clear up the issue after being unable to delete through windows explorer. I created a blank folder called purge and then ran the following to clear the folders:

ROBOCOPY source C:\PURGE\  dest BACKUP PATH\APPLICATION DATA  /PURGE

Since the source folder is empty robocopy will delete everything in the destination path regardless of filename length.

This really solve the problem you have. The correct syntax is:

robocopy c:\purge d:\users /purge

where "d:\users" is the infinite loop path

Also make sure to create a blank folder named "purge" in c:\ as mentioned above

Run the robocopy command a few times until it delete all the copied folders. It works for me.

Answer 4

This happened to me as well.  In addition to regular backups, I use(d) Robocopy to create file-level mirrors for convenient access to older versions of frequently changed files on XP.  After upgrading to Windows 7 Ultimate N 32-bit, the mirrror operation started to create recursive Application Data folders on the target volume.  I believe this is caused by path aliases created by using NTFS junctions in order to provide a backward-compatible filepath for common files (such as application settings, etc.).  It will create the subdirs recursively until the volume is full, but long before that, the effect you experienced happens: the path becomes too long to manage or even delete using Windows tools.   I had to reformat the volume to recover.  Thank goodness I was doing a root-to-root mirror and not mirroring to a subdirectory on a volume used for other things, or I would have had to mount it in Linux to prune the filesystem tree and still retain the other data on the volume.  I find it amusing that even the latest versions of Windows allow one to create a directory structure that the OS cannot delete.