Stop Application Data folder replicating?

i went to the 3rd junction of "Application Data" ( had over 200 of them) and just deleted...NO problems. I can understand there can be TWO junctions with the same name, but 100's? NO WAY!

I THEN only "added" the EVERYONE = DENY

Ok, I am in the same boat with the multiple replicating Application Data folders, most likely due to taking ownership of something I shouldn't have. I downloaded the Junction Box application, made a back up, and then attempted to Restore the default Junctions, but I am getting the attached error about a "Possible Compatibility Issue". However, it's recommended action ("... then add WIN_LONGHORN to the OSVersions value in the backup file, and proceed") appears unnecessary as the 'DefaultJunctions.ntj' file already has this:

[General]

; Displays warning if incompatible OS or system-language is found.
OSVersions=WIN_VISTA,WIN_7,WIN_2008,WIN_2008R2,WIN_LONGHORN
OSLanguages=0409,0809

BTW, not sure how I have done this, but I also have actual files apparently stored in some of these quasi-folder junction locations, so I am a little leery to just start chopping away at some of these multiple Application Data folders.

I am using Windows 7, 32 bit. Does anyone have any insights into this 'Program Compatibility Issue' with Junction Box or advice on how I should proceed?

Thanks!

Jeff

There are no sub folders to Applications Data. There is only ONE. What you are seeing is a loopback. Application Data is a junction that points to its parent folder. The multiple "Application Data" folders are one in the same. Its like two mirrors fancing each other. they reflect off one another creating an infinite tunnel.

...It does not take any SPACE! my god...and their is no second Application Data folder. This cannot be that hard to understand. If you go into "Application Data" you will see a second one, but it is the same one you just entered. Deleting it deletes the first one. Because their is only one! The fact of the matter is, you are not even suppose to be able to enter them so this does not happen. Should return permissions back to what they were previously.

Also putting a file inside is impossible, IMPOSSIBLE! "C:\Users\[username]\AppData\Local\Application Data" points to "C:\Users\[username]\AppData\Local" trying to put a file in it goes to "C:\Users\[username]\AppData\Local\some\sub\directory"

it IS possible to put a file in there...

What i'm TRYINGGGG to say is....even a SYMBOL you type, takes up space...even if it's just ONE BYTE!
If you place ANY file in a Aplication Data directory...it will ONLY reflect when going in VIA "Local Settings"....if you click on the Application Data WITHOUT going through Local Settings...you WONT see the file entered ( ie entering the file in the 4th Application Data, wont show up if you enter the Application Data DIRECT! I KNOW its junctions (or "links" for short")...but even a LINK is data written to the disk....SAVY?

RobinHood, I hate to say it, but logicearth may be correct, even with what you think is proof. Until you search and see if "New Rich Text Document" exists in a file inside Local Settings, you have not proved your point. If you are unable to find it within that folder through an extensive search, then you will have proof.

Edit: I am actually leaning toward RobinHood's discovery after reading whocares's post Stop Application Data folder replicating? #3 about junctions. I believe that once that folder is given permissions and other programs access it incorrectly as a folder rather than a junction, it creates a long line of folders that can have individual data stored in them, thus taking up space. Though this is not the intention of Application Data, it is what happens once that folder permissions are altered.

This is why robocopy should be used with the /xj (exclude junctions) option when copying user folders. I used robocopy incorrectly once and generated a 20 GB sized Application Data folder that should have only been a few hundred MB.