Inaccessibility of 'Application Data' folder prevents debugger from opening.

[GoogleCodeExporter]

What steps will reproduce the problem?
I was using this feature just fine for quite a while, and suddenly it stopped 
working. I guess the first thing to do would be:
1.On a windows machine, using java, run this code to find the relevant 
directory:
System.out.println(System.getProperty("user.home"));
On my machine is was c://users/username.
2. Go to that directory and see if a folder called "Application Data" exists. 
If it does, make it inaccessible somehow. I don't actually know how to do that, 
but on my Windows 7 machine it's inaccessible because it is a shortcut to 
somewhere, and when I click on it, it says "access denied".
3.Try the following Java code:
Kernel kernel = Kernel.CreateKernelInNewThread();
Agent agent = kernel.CreateAgent("testAgent");
agent.SpawnDebugger(Kernel.GetDefaultPort(),new SoarProperties().getPrefix());
System.out.println("worked");

What is the expected output? What do you see instead?
I expect a debugger to popup, but none does. The string "worked" is still 
printed.

What version of the product are you using? On what operating system?
Soar 9.3.0, Windows 7 64 bit.

Please provide any additional information below.
The bug is not traceable with the Java debugger using the above code. But if 
you import Application from the debugger jar you can step through the code from 
here:
Application.main(new String[]{});
It turns out that the culprit is in the GetSettingsFilePath() function on line 
65 of AppProperties:
   if (osName.toLowerCase().startsWith("windows"))
    {
      homeDir = new File(homeDir, "Application Data");

      homeDir = new File(homeDir, "SoarDebugger");
    }
There is no error checking done for the accessibility of the Application Data 
folder. I'm not sure what happens after java fails to open the file, but it 
never returns from it.

Original issue reported on code.google.com by garfield...@gmail.com on 24 Dec 2010 at 8:05

[GoogleCodeExporter]

Changing user account controls doesn't fix the problem, but setting the user 
home to somewhere else is a temporary fix:
System.setProperty("user.home", "C:/Users/me/Desktop");

Original comment by nathan.g...@gmail.com on 7 Jan 2011 at 5:13