Question

Q: Windows 7 infinite loop while using Robocopy

.  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

A:

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

Did this resolve your issue?

Sorry this didn't help.

15 people were helped by this reply

Answer

A:

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.

Did this resolve your issue?

Sorry this didn't help.

1 person was helped by this reply



progress
 
Question Info

Views: 54564 Last updated: October 11, 2017 Applies to: