Windows 7: Stop Application Data folder replicating?

That virus information you linked to...Its not storing anything in those junctions. It is just that the user opened all of those junctions by changing the PERMISSIONS and now see duplicated data again and again. However the files in question are only located at "C:\Users\[username]\AppData\Local\Temp" That is all. The permissions applied to these junctions are there to prevent this kind of confusion. If you can access "Document and Settings" you have just screwed up.

NOW you are talking sense (with all due respect...and i mean it) . THIS was my whole issue...Hope you dont mind, but i'm going to use the word "Virtual"-links and "Virtual" files...call them whatever you like
What I'm trying to do is, seeing MS only ( or at least TRY to ) manage these virtual links/files to only about 2-3 levels deep, and i work with an "infected" PC ( only a nut will try this on a PC thats NOT infected...there i agree 100% with you ), the program backs-up the the data up to the 2nd link ( which i call a "level 3" ), then DELETES the remaining link...chances are you might loose "links"...but the data will remain. This way you dont need to do a Format of Windows 7. A lot of my clients treasure data more than their PC's...therefore i need to ceate a utility, that can AT LEAST HELP me....to recover most of their data. To try and "locate" data, that extends from a link 200 deep, well...now we're talking a day's work. I will rather loose the program and save my data, than save my program and loose my data...if you know what i mean? This utility is also NOT meant to be stuffed-around with as you will do more damage than good....the Utility was/is meant for Techs that needs to recover data on an ALREADY infected PC...

@RobinHood
On a Windows 7 machine, there is no "C:\Documents and Settings" folder. It is a Junction that points to "C\Users". If this is still the case, @logicearth has provided the solution several times. Fix the permissions on "C:\Documents and Settings", and all the files and folders below it will go away. Rinse and repeat for the "Application Data" Junctions, and your problem will be solved. The folders never existed, and therefore, there is nothing to cleanup. If "C:\Documents and Settings" is an actual folder, you have bigger problems, and you should keep reading.

The reason for using technical terms when possible is to avoid confusion. For example, the word "cat" can refer to several different animals, and a house "cat" is vastly different from a lion "cat". Which "cat" you are referring to can make a big difference. What you mean by "Virtual" is important, and I do not think you are using it the way we are.

The "Special Folders" link is a no-technical overview, but technically, it is worthless. The "virtual folders" they are discussing are actually Shell Namespace, and the article does mention this. Shell Namespace can be displayed as a folder, but they are not folders. A better description of Shell Namespace would be "an amalgamated set of data presented as a virtual folder", but that is still not technically adequate. Using this article as a technical reference will lead result in problems at best.

System Folders are not virtual. They are real directories. In Windows 7, Microsoft has changed the locations again, but they have tried to fix the mess they have been causing. All the previous System Folders are included as Junctions, but this has resulted in a tangled web of connections. The "Application Data" Junction points to its parent folder, and this regression results in multiple nested "Application Data" folders. For the end user, it is confusing, and it can be dangerous. Deleting files in the 200th "Application Data" folder also deletes it in all the "Application Data" folders. In addition, Copy/Paste do not understand Junctions, and they are treated as actual folders. As I noted in an earlier post, this will result in an increased storage space used. Backup applications can also duplicate Junctions as folders, and the result is that the backup has more data than the original. Through the use of security/permissions and a special User, Microsoft eliminated this issue.

If "C:\Documents and Settings" is still a Junction, everything being displayed in the it is actually in the "C:\Users" folder, and deleting files in one place will delete them in both. On Windows 7, deleting a Junction in Windows Explorer will not delete the files and folders, but on Windows XP, all the files and folders will be deleted. If you write a utility that deletes a Junction, it needs to be able to identify the Operating System version. Otherwise, it is irresponsible and dangerous. I have a serious problem with that.

Unless you can determine whether "C:\Documents and Settings" is a Junction or an actual folder, your utility will be either useless or dangerous. If you have access to the machine, use the command from my previous post to identify the Junctions, and proceed from there. You could write a script that could do some of this, but it should only be used by someone who understands the technical aspects. Using a HighjackThis report, you cannot determine if you have a Junction or a folder. Furthermore, I know that there should be more files in "Application Data" than four temp files. I do not know why the HighjackThis report is filtering the files, but this could cause problems.

I could be wrong, but my guess is that this is not related to the trojan being discussed in the linked discussion. The user probably took ownership of the C: drive, and he/she gave themselves full permissions. The machine then was infected with the trojan. A HighjackThis report was submitted, or you have access to the machine. In this scenario, the folders and files you are seeing do not exist, and therefore, you cannot delete only the additional subdirs without deleting everything else as well. Here is the command "dir /al /s c:\". Run it without the quotes

JunkTidy all it does it locks up on me everytime. So I am sticking with JunctionBox at least it works.