Processing cannot run because it could not create a folder to store your settings.

[processing-bugs]

Original author: cpuro...@gmail.com (October 15, 2010 14:59:46)

This refers to the following 2 bugs:
http://processing.org/bugs/bugzilla/585.html
http://processing.org/bugs/bugzilla/1016.html

What steps will reproduce the problem?

1. Have a domain user with roaming profile login to a computer for the 1st time. Logout, this will now store the roaming profile(including the user's registry hive) on the server and erase the local cached copy of it.
2. Have a local user with the same username login to the same computer for the 1st time, this will now create a user profile with the same name as the domain user.
3. Have the domain user from step1 login again and run processing.

Expected output: Processing runs.
Actual result: Processing does not run with the following error message "Processing cannot run because it could not create a folder to store your settings."

What version of the product are you using? On what operating system?
Processing 1.2.1 on Windows 7(This would however most likely also occur on Windows 2000, XP and Vista)

Please provide any additional information below.

I've narrowed down the bug to the fact that Processing wrongly assumes that the paths specified in the following registry section are always correct.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

When the domain user logs in to the same computer in step 3, the user's profile folder on the computer will now have a .domain suffix appended to it, as in the name of the domain the user belongs to. This is standard windows behavior to avoid a collision with the existing local user's profile folder.

The issue in Processing occurs because Windows will never update any of the entries in

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

after they were 1st created to match the new profile folder path with the .domain suffix appended to it, so Processing tries to write to the non-domain user's profile path, which of course it doesn't have rights to.

Microsoft even put in a notice in that said Registry key labeled: "!Do not use this registry key - Use the SHGetFolderPath or SHGetKnownFolderPath function instead"

The reason being that the data in that key will not be valid all the time.

Original issue: http://code.google.com/p/processing/issues/detail?id=410

[processing-bugs]

From Chris.Lonnen on November 30, 2010 19:52:31
This is tricky because its not the key, but reading the registry itself that was depreciated, starting with Vista. SHGetFolderPath and SHGetKnownFolderPath are not available in Java.

Instead, Java users are supposed to use System.getProperty("user.home"), which is buggy and incorrect for vista, and windows 7, as well as XP with roaming profiles enabled. See bug 4787931 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4787931), which was supposedly fixed, but reappeared in Java 1.6 as bug 6519127 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519127). It has an unknown cause and is listed as a low priority.

Most solutions I've seen argue that our current method is the best way to work around this problem, although one particularly grumpy Stack Overflow user demanded a cross platform solution to work around this and eventually settled on System.getenv(String name) as the best option.

[processing-bugs]

From f...@processing.org on November 30, 2010 20:28:37
Hm, I thought it would be JNA to call SHGetFolderPath or SHGetKnownFolderPath instead of the registry functions, though perhaps that doesn't work as well.

Do APPDATA and USERPROFILE exist consistently across XP through Win 7? Although USERPROFILE doesn't give us the My Documents folder which is what we'd want (since we can't use the "My Documents", we need a localized version).

[processing-bugs]

From Chris.Lonnen on November 30, 2010 21:17:29
I hadn't thought of that. I found an example and I'm going to give that a try. Looks like CSIDL_PERSONAL is 'My Documents' and CSIDL_APPDATA is the 'AppData' folder we need.

I only have Windows XP to test this on. I'll post the patch here when I get it working.

[processing-bugs]

From Chris.Lonnen on December 01, 2010 21:16:11
Ok, here's the patch. I've verified it works on my Windows install. It involved adding another library wrapper to processing.app.windows.Platform.java and a few empty static classes to appease SHGetFolderPath().

I don't have access to an environment where I can test it against the original bug report. Let me know how to proceed.

[processing-bugs]

From Chris.Lonnen on December 01, 2010 21:25:33
Fixed the patch name.

[processing-bugs]

From f...@processing.org on December 01, 2010 22:05:59
Thanks, please go ahead and check this in.

[processing-bugs]

From Chris.Lonnen on December 01, 2010 22:54:52
Checked in as r7473.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.