FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :
 customer  Windows XP [Version 5.1.2600]

ADDITIONAL OPERATING SYSTEMS :
All Windows


A DESCRIPTION OF THE PROBLEM :
The Java runtime looks (as far as I can see) at the
Registrykey
"[HKEY_CURRENT_USER\Software\ customer \Windows\CurrentVersio
n\Explorer\Shell Folders\Desktop]"
and strips the last directory of this value.
As this is a derived value from a Registry-key whose
purpose is *NOT* to point at the users home directory, this
behaviour is likely to fail.
We have seen some cases, where the mentioned registry entry
changed during a windows session or after a restart. So a
Java-program's behaviour depends on when the user has
started a programm (before or after the change to the
registry, which the user probably does not know about).
After all, its really difficult to track down the reason
for a java-programs malfunction, because the mentioned
registry entry is not easy to find, and the Environment-
variable "USERPROFILE" - which should be the source
of "user.home" (this is my opinion) - does not
influence "user.home" at all.





STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.change the above windows registry value to an other value
(e.g. "c:\MyDesktopFolder")
2.run PropertyTest.java
3.type "set USERPROFILE" inside windows cmd-line (shell)

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected Result:
PropertyTest returns what Windows thinks is the User Home
directory, which should be the same value as "set
USERPROFILE" returns, e.g. "C:\Dokumente und Einstellungen\TestUser1".

Actual Result:
PropertyTest returns "C:", whereas "set USERPROFILE" still
returns "C:\Dokumente und Einstellungen\TestUser1" !


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
/* precondition:
alter "HKEY_CURRENT_USER\Software\ customer \Windows\CurrentVersion\Explorer\Shel
l Folders\Desktop" prior to running this test */

public class PropertyTest{
  public static void main(String[] args) {
    System.out.println(System.getProperty("user.home"));
  }
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
No simple workaround for us, since it depends on how our
customer deploys our application to his employees.

Reading the Environment-variable "USERPROFILE" on
Application startup is not that simple because of other
java-bugs (Exec for batch-files...).

If a customer has a problem (most often, our Application
won't start at some time (hopefully not during a
presentation to the management ;-(, because the "user.home"
is different, and the license-information file can not be
found anymore), we can tell him to manually edit the
registry, which is so awful and unprofessional for
a "professional application plattform" like java should be
one.
(Review ID: 178403) 
======================================================================
Posted Date : 2005-09-14 20:42:40.0

J2SE 1.5 will have a working System.getenv(String), so users can simply
do a System.getenv("USERPROFILE") directly.

  xxxxx@xxxxx   2004-03-19

Will investigate fix for Tiger; problem has existed since 1.3.

  xxxxx@xxxxx   2002-12-09

It is not at all obvious to me what the correct value for java.home should be.
When I log in to my Windows machine using ssh, I see

HOME=C:HOMEDRIVE=d:
HOMEPATH=\martin
USERPROFILE=C:\WINNT/Profiles/martin

Three different values, and the directory C:\WINNT/Profiles/martin doesn't
even exist!

When I log in the traditional way on the console, I get

HOME=C:HOMEDRIVE=C:
HOMEPATH=USERPROFILE=C:\Documents and Settings\martin

which is a little more consistent, and the latter directory
actually exists.

Given that HOME is what is used on Unix, and given that this
variable exists on Windows, I would favor this algorithm:

if HOME is defined, and names an actual directory, use that.
if HOMEDRIVE and HOMEPATH are defined, and name an actual directory, use that.
if USERPROFILE is defined, and names an actual directory, use that.
else use the root directory of the drive where the windows system directory
is located (typically C:\).

But I am not a real windows user, and I am not familiar with the
culture enough to know what most users would expected.

An argument for HOME is that this variable appears to be used by
"Command Prompt" for its initial directory.

  xxxxx@xxxxx   2004-03-19

       The registry approach used by the JDK is definitely wrong. The
suggestion in the evaluation is also problematic because
HOME/HOMEDRIVE/HOMEPATH don't exist in older Windows platforms, and
there are many bugs documented in MSDN that these variables are not set
properly by Microsoft in various situations.

	To determine the user profile correctly on Windows, there are really
two ways to do it:

1. Use %USERPROFILE% environment

	This variable is normally set to the actual user profile location by
Microsoft. The advantages is that it works on various Windows platforms
with various types of user profile settings:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/xpusrdat.mspx

	However, older Windows (e.g. Windows 95/98) is more or less a single
user system, so settings up user profile is not required for end users.
In these OSes, %USERPROFILE% would not be set by Windows, but Windows
itself would default the profile location internally to Windows
directory.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/shlwapi/registry/shreggetpath.asp

	Thus, the correct algorithm in this case would be:

	if %USERPROFILE% is present	{
	   Set "user.home" to value of %USERPROFILE%
	} else  {
	   Set "user.home" to Windows directory
	}

	This scheme works in general, and it basically mirrors the internal
algorithm used by Windows. There is still a catch - because the value is
set in environment variables, if the user happens to change the user
profile location on-the-fly through Windows Control Panel, %USERPROFILE%
will reflect the new value only in new processes;  
%USERPROFILE% in all the running processes will still have the old
value. Users could also override USERPROFILE in the shell which may
cause unintentional side effect.


2. Use SHGetFolderLocation or SHGetFolderPath APIs

	These APIs are actually the recommended way from Microsoft to determine
special folders in user profile on Windows:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_new/fastuserswitching.asp

	These APIs generally return the special folder location under the user
profile:

	C:\Documents and Settings\<username>\<special-folder>

	You could determine the user profile by looking up the parent directory
of the returned path. Thus, the algorithm would be something like

	if shfolder.dll is present	{
	   SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, pszPath)
	} else if shell32.dll is present	{
	   SHGetSpecialFolderPath(NULL, pszPath, CSIDL_APPDATA, TRUE);
	}
	Set "user.home" to parent directory of pszPath 	   


	The nice thing about using these APIs is that they could provide the
user profile location programmatically without suffering the drawback of
environment variable scheme in general. 

	This scheme also works in most cases. The catch is that these APIs are
from shfolder.dll and shell32.dll, and these DLLs only present if
Internet Explorer 4 or later is installed. Although IE is almost
pre-installed with every Windows OS, Windows 95 and Windows NT4 are the
exception. Loading shfolder.dll and shell32.dll would also have minor
footprint impact because additional Windows libraries are now required
to run the Java apps.



	In general, the end result of using #1 and #2 would be pretty much the
same, and it is simply a matter of choice. In plugin, we used #1 for
determine the "user.home" settings for simplicity, and we used #2 to
determine special folder location. Since JRE only cares about user
profile location for "user.home", I would suggest #1, so it will be
consistent with plugin. #1 was also suggested by many customers in early
releases of plugin to workaround this particular "user.home" in the JRE,
so this fix should be well-received by customers. The only potential
issue for customers is backward compatibility of "user.home", but we
should fix it anyway because it is really a bug.

  xxxxx@xxxxx  

I have done some more investigation.  The windows system I was using
(Win 2003 Server 64-bit) has both the concept of a "User Profile" and
a "Home Folder" (which I think is the same as the "Home Directory"),
as can be seen from per-user properties in the menu tree
Administrative Tools ->
Computer Management ->
Local Users & Groups ->
Users

If the Home Folder is unset, it defaults to the User Profile, which
in turn defaults to %SYSTEMDRIVE%Documents and Settings\%USERNAME%.

Windows (at least in the interactive session) will initialize
%HOMEDRIVE% and %HOMEPATH% to point to the Home Folder, and will
set HOME=%HOMEDRIVE%%HOMEPATH%.

Intuitively, it seems clear we should set user.home to the same value
as the Windows Home Folder, at least on modern Windows systems.
Which means we should use %USERPROFILE% only as a fallback.

There is a programmatic API to access the home directory.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netmgmt/netmgmt/netusergetinfo.asp

NetUserGetInfo returns in its USER_INFO_1 structure, the member
LPWSTR usri1_home_dir;
which seems to be exactly what we want.

My current recommendation is:
Check if HOMEDRIVE and HOMEPATH are defined, and name a directory.
If not, use the NetUserGetInfo API to extract a valid home directory.
If that doesn't work, try %USERPROFILE%.
If that doesn't work, try the root directory of %SYSTEMDRIVE%

This seems to be consistent with "Command Prompt".

  xxxxx@xxxxx   2004-03-23

Actually, there is a workaround.  
http://access1.sun.com/cgi-bin/rinfo2html?354930.faq

We have redirected desktops here too. This may not 
be a 'bug' but it is a very bad design decision. It breaks 
Weblogic Workshop and MKS Enterprise client, no 
doubt amongst other apps, and has personally cost 
me a lot of time and folicles. (I use -
Duser.home="u:\java" as a workaround)
chrispy

The Workaround of echotester2003 is no solution for 
us, because we can not say our customers to sitewide 
change their Desktopsettings to be elsewhere, only 
because there is a bug in Java that will not be fixed by 
sun. This is a real Desktop-Java acceptance issue 
(and there are lot of them in the bugdatabase). 

Hey SUN! 
Why can't I see any fix for this in TIGER ???
It's not that difficult to solve this.
So what are you doing?

Duser.home="u:\java" doesn't work for me....seems 
this variable can't be set in 1.4.1+(?)
The bug makes it impossible for my application to run 
on citrix / terminal services...

Evaluation now seems to be ok.
Maybe take current algorithm in account, if neither 
HOME, HOMEPATH and USERPROFILE is defined (for 
backward compatibility).
When you logged in using ssh, the USERPROFILE 
had a value similar to those ones you get when 
logging in on old Windows NT 4.0 ... 
Maybe this is an issue with your ssh login ?

This really needs to be a configurable item for the default cache location.  
If I want to install an application for many users to share on one PC, there is no way to do this anymore.  I would have to sign on as every single user and install the application for each one individually.  We chose WebStart so we don't have to do this, and we don't have to use a browser. 
Please fix this problem.  It used to work fine when it was a 'bug'.

This bug has had quite some impact on me and the university I teach at. The domain setup is using redirected desktops and this basically messes all Java applications up.  What we have to do is map the users profile to a drive letter (o:\) and add -Duser.dir=o: to all Java application startup scripts.

This is really annoying and I must say that I'm having a hard time understanding why this hasn't been solved a long time ago (this is the second year I've had to work around this problem in the setup of the computers at the school). This bug is of such importance that I would like to request that when you fix it you not only put in into Tiger but also put it into the next version of 1.4. 

All our clients map the desktop directory to a fileserver which means the user home directory is resolved to the remote server instead of the local PC.  This bug makes Java WebStart applications essentially _unusable_ in our environment.  PLEASE FIX THIS BUG.

Well, I'm guessing that I'll have to apply the quick and dirty fix to all Java applications that will be set up in the University for the third year.

What exactly is it that results in such an unnaturally long time that it takes Sun to fix these kinds of bugs?

hi,
i am facing same problem that user.home is not giving user profile , how can i get correct solution.

This is causing us major problems under Citrix, as we too have redirected the desktop.

Versions affected are: Oracle Jinitiator (wrapper around 1.3 JVM), 1.4 and 1.5. 
A fix would be much appreciated.

Test comment.
Please ignore.

Test comment

Test Comment

Affects Java EE bundle/ Netbeans installers as well. The installations mention "The default location for the installer working directory is %USERPROFILE%\.nbi on Windows and ~/.nbi on other platforms. ". However, the USERPROFILE is ignored. JDK1.6.0_01, windowsxp

Hey folks, this registry key still changes ON THE FLY !!
We've still so many support cases where this BUG is the reason for. So please! Fix is soooo easy using above evaluation!

Above comment was added under the wrong Account-Id (bug in loginsystem of the BugDatabase). The correct Account-Id were "schlm3".

Can someone update the bug details? This affects all vresions up till 1.6.x. Please fix!

This did also cause us a lot of headache.
The other problem is, that the current implementation does not help to get die "Desktop", "My Documents", "Local Settings", "Application Data" etc. folders securely inside Java w/o using some kind of Windows Registry access tools from within Java.

I've run into the same problem trying to get Eclipse to run on the domain with roaming profiles. I've been banging my head for days thinking it was an Eclipse issue, but found a work around in the config.ini. The problem I then realized was with Java and the user.home data. The end result was config files were going into \\xxxx\\User Profiles\ACCOUNT\ instead of \\xxxx\\User Profiles\ACCOUNT\Profile\. We've seen this behaviour before and I'm betting those programs we're Java apps also. I have yet to confirm that, but I read here a similar post. I'm sure it's not so clear cut, as there may be a solution on the horizon, but implementation is not always straight forward. However I will say that this should have been fixed within the first year or so of XP being released being that roaming profiles became common, atleast in my experience, in business environments. PLEASE!! GET THIS FIXED!!! I've lost a good amount of time developing because this had to be solved for my IDE to work on the domain.

Not really a constuctive post, I know, but the more info the better I suppose.

Still affects 1.6.0_07-b06

This really is still an issue. It's still not working. damn.

Still exists in 6u11.  It's been 6 years now.  It's affecting our end users.  So let's get it fixed please.

The following swing class seems to have some methods for accessing these directories:

FileSystemView.getFileSystemView().getDefaultDirectory()

A possible small work around at least.

Still exists on Java 6 Update 16.

This bug makes deploying Java Webstart applications on Citrix or any system using redirected desktops nearly impossible. At least update the javaws command line so people can workaround this 6+ year bug using the -DUser.dir or -DUser.home options.

We are using Eclipse RCP applications on Citrix and this is cause us major issues as well.  I'm trying to figure out why this is marked as low priority when it is in the 10 ten most voted for bugs.  

This bug messes up Java ME Device Emulator as well: When the Desktop is redirected to a network share where the user has no write access, Device Manager will not be able to find any devices. Look at the Netbeans ME forums if you want to get an idea of how many people are actually affected by this bug.

I've had a similar problem and have written a small javaagent that corrects the 'user.home' value with the path from windows call SHGetPathFromIDList(...).

The lib works, but is considered experimental :) I'll use it until this is fixed.

http://code.google.com/p/jdatapath/

Hope this helps some of you :)

Sun:  Please, PLEASE fix this.  It continues to cause problems even after all these years.