Changes in the user.home directory

This problem has become a real problem for us as well, as with any big company, having roaming profiles is a must, and with that, the file transfer feature button does not work with that type of scenario..

Hello!

I am pretty sure the above default directory for Windows is not 100% correct because of:
1. It is named differently on each locale of windows. In German "documents & settings" are called "Dokumente und Einstellungen" etc...
2. Quite a few system pathes have changed with the new Windows VISTA.
3. The home dir doesnt need to be on %%rootdrive%%

Maybe http://msdn2.microsoft.com/en-us/library/aa367565.aspx -> Windows Installer -> property reference helps to construct a more universally useable directory name ...

Hope this helps

"%USERPROFILE%\Spark" it the directory Spark uses on my Windows installation.

"%USERPROFILE%\Spark" is the directory Spark uses on all Windows installations, it should be changed to "%USERPROFILE%\Application Data\Spark", as msi installers can not target the root of %USERPROFILE%. It is a physical restriction in msiexec.exe as well as most comercial msi compilers.

These are the only generic target destinations available to msi installers:

AdminToolsFolder The full path to the directory that contains administrative tools.
AppDataFolder The full path to the Roaming folder for the current user.
CommonAppDataFolder The full path to application data for all users.
CommonFiles64Folder The full path to the predefined 64-bit Common Files folder.
CommonFilesFolder The full path to the Common Files folder for the current user.
DesktopFolder The full path to the Desktop folder.
FavoritesFolder The full path to the Favorites folder for the current user.
FontsFolder The full path to the Fonts folder.
LocalAppDataFolder The full path to the folder that contains local (nonroaming) applications.
MyPicturesFolder The full path to the Pictures folder.
PersonalFolder The full path to the Documents folder for the current user.
ProgramFiles64Folder The full path to the predefined 64-bit Program Files folder.
ProgramFilesFolder The full path to the predefined 32-bit Program Files folder.
ProgramMenuFolder The full path to the Program Menu folder.
SendToFolder The full path to the SendTo folder for the current user.
StartMenuFolder The full path to the Start menu folder.
StartupFolder The full path to the Startup folder.
System16Folder The full path to folder for 16-bit system DLLs.
System64Folder The full path to the predefined System64 folder.
SystemFolder The full path to the System folder for the current user.
TempFolder The full path to the Temp folder.
TemplateFolder The full path to the Template folder for the current user.
WindowsFolder The full path to the Windows folder.
WindowsVolume The volume of the Windows folder.

You could actually use %appdata%\Spark on windows as this will get you into the right application data direction regardless of the windows OS being used.

This bug is also causing my organization serious trouble. See details in: http://www.igniterealtime.org/community/message/159015#159015

Also, see this thread: http://www.igniterealtime.org/community/thread/29048

This has been ongoing for quite a while, with little or no communication on possible fixes/resolutions. Are there any plans by the Jive team to look into this issue further? We really need a resolution shortly.

Hi folk! So.. moving where the preferences are stored and such is trivial. Wouldn't take me much time at all to do that. The real "difficulty" here is in carrying over the user's original settings. I don't want all of the end user's settings to just suddenly vanish on them, that's not very nice. =) In theory a couple of simple tests should take care of this ...
if [ new location exists ] don't touch anything
if [ new location doesn't exist, old location does exist ] move folder to new location

Just need to make sure everything is kosher. =) I'm open for any thoughts y'all have or warning if you think of something I might not be thinking about.

I also need to consider where this should go under unix systems. I'm actually thinking the general standard there would be something more like .spark in their home directory.

I'm going to try to have this fixed for 2.5.9, but it may not happen. =)

The only thing I would add to this is to make the directory settings for the preferences, etc, a configurable item through some means, most likely the preferences section in the spark gui. This way it can easily be moved when someone needs it to be different.

Do we know when the fix for this issue will be available? The issue is referenced across a few JIRA tickets SPARK-899 for example.

I noticed that the code in the trunk has been modified.

The code currently in org.jivesoftware.Spark.java http://svn.igniterealtime.org/svn/repos/spark/trunk/src/java/org/jivesoftware/Spark.java (7/26/09) defines USER_SPARK_HOME, first as

System.getenv("APPDATA")+"/"+getUserConf()

and if that fails, then as

System.getProperties().getProperty("user.home")+"/"+getUserConf()

With this change, users with roaming profiles should no longer be troubled with the Sun JVM issue related to the value of user.home, as documented at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4787931

Users with roaming profiles still are not 100% OK since APPDATA is local to the current computer and thus their setting will not follow them around, but at least this set of users will be able to use Spark. Note that an alternative to using APPDATA is to use USERPROFILE.

If you cannot wait for the next versioned release of Spark, I simply took the 2.5.8 tag from Subversion http://svn.igniterealtime.org/svn/repos/spark/tags/spark_2_5_8/ and modified it with the above code and things worked well in my environment.

Users with roaming profiles still are not 100% OK since APPDATA is local to the current computer and thus their setting will not follow them around, but at least this set of users will be able to use Spark. Note that an alternative to using APPDATA is to use USERPROFILE.

This is not correct. %APPDATA% points to the roaming application data folder, regardless of whether you are using Windows XP (%userprofile%\Application Data) or Windows Vista (%userprofile%\AppData\Roaming).

The folders that do not roam are
Win XP: %userprofile%\Application Data\
Win Vista: %userprofile%\AppData\Local\

Also, %userprofile% should never be used to store application data, nor should it be used to construct the path to application data.

Andrew, Thanks for the feedback. I have to speak with the folks who manage our desktops where I work, inquiring about what appears - based on your comment - our "semi-"roaming profiles. What I wrote above worked in our (convoluted?) environment; my hope was that someone else might benefit from how I resolved this issue.

What variable do you suggest should be referenced to place the user's data in?

The Spark application data should be stored in the location referenced by the Windows enviornment variable %APPDATA%

We use group policy and redirected folders in our place and so our %APPDATA% folder is stored on a remote network share. This policy can be applied to Windows 2000,XP,Vista and 7 and so %APPDATA% is set to wherever it is configured for in the policy for example \\server\username\appdata

On Windows Vista and Windows 7 %APPDATA% for a [local] user with no redirection group policy in place the %APPDATA% path is set to:

C:\Users\username\AppData\Roaming

On Windows XP, again for a [local] user with no redirection group policy in place the %APPDATA% path is set to:

C:\Documents and Settings\username\Application Data

Any data that is only really required for the session and doesn't need to be kept, or specifc to that user on that computer should be stored under the Local appdata. Windows Vista and Windows 7 both store this as an environment variable called %LOCALAPPDATA% (which equates to C:\Users\username\AppData\Local) however this is not true for Windows 2000 and Windows XP, where you would have to user %USERPROFILE%\Local Settings\Application Data which equates to C:\Documents and Settings\username
Local Settings\Application Data

Hope that helps somewhat. I would like to be able use Spark, but until I can stop my other part of profile being bloated I can't.

Richard, you cant try the latest SVN version and see if it finally works correctly. Spark saves profile in AppData now. http://www.igniterealtime.org/community/docs/DOC-1822

Just tried installing spark_2_6_0_11093_online.msi and run spark and I can confirm this is still NOT working. As you can see from the dir command below on my Windows 7 machine that the Spark directory is still being created in %USERPROFILE%\Spark instead of %APPDATA%\Spark.

C:\Users\my_username\Spark>dir
Volume in drive C has no label.
Volume Serial Number is ABCD-AB12

Directory of C:\Users\my_username\Spark

05/10/2009 21:38 <DIR> .
05/10/2009 21:38 <DIR> ..
05/10/2009 21:38 <DIR> bin
05/10/2009 21:38 <DIR> logs
05/10/2009 21:39 <DIR> plugins
05/10/2009 21:38 <DIR> resources
05/10/2009 21:41 244 spark.properties
05/10/2009 21:39 <DIR> user
05/10/2009 21:39 <DIR> xtra
1 File(s) 244 bytes
8 Dir(s) 41,762,033,664 bytes free

ah, forgot to point out that you should try exe or jar one (11186 build), because msi is a bit older build

Thanks wroot. Downloaded spark-installer.exe.zip, unzipped and installed as an Administrator using the command-line:

C:\Program Files\Java\jre6\bin\java.exe -jar C:\Downloaded\spark-installer.jar

I can confirm that this version DOES indeed place the Spark application data folder in the correct location. I did notice that the following directories were still being created in %USERPROFILE% though, and these should perhaps move to %APPDATA% as well:

.jmf
.jmyspell

When do you think that an msi and/or final build might be ready?

Just to say I've also checked this on my work PC with a Group Policy Redirection policy in place and the 11186 build works as we were expecting and the Spark directory is created on my network shared where my %APPDATA% is stored. My previous comments still stand true regarding .jmf and .jmyspell folders as well though.

Let's hope cstux will notice your comments (or you can also comment on that doc with svn versions) and fix that as well.

this has been adressed already

osx path is in ~user/Library/Application Support/Spark
win path is %APPDATA%/Spark

Mass closing of all bugs resoved during 2.6.0 and 2.6.1