Hi,
after studying many MSDN docs, I think you are right, to use CSIDL_PROFILE.
And as I read ...
* Note: To save space we want to avoid loading SHELL32.DLL
* unless really necessary. However if we do load it, we leave it
* in memory, as it may be needed again later.
I'm pretty sure, we should not use this trick anymore.
One note from my side on Windows XP:
"HOME": not existent
"HOMEDRIVE": C:
"HOMEPATH": \Documents and Settings\username
So to get "C:\Documents and Settings\username" one has to concatenate "HOMEDRIVE" +
"HOMEPATH"
-Ulf
Am 23.10.2012 09:52, schrieb Sean Chou:
Hi Alan,
I did some search and wrote a brief, hope it helps.
=====================================
A brief about home directory, user profile directory, and "My
Documents" directory of windows users.
In windows NT and early, there is an assigned home directory act as a
user's default folder to "Open and Save files"[1]. It is represented
by environment variable "HOME", "HOMEDRIVE", "HOMEPATH". And this is
still available in windows 7, a home directory can still be assigned
to a user and %HOME% will report the assigned directory[7]. By
default, HOME is set to profile directory which is "C:\Users\username"
in vista and 7, and "C:\Documents and Settings\username" in XP(cmd ->
set HOME).
In windows 2000 and XP, "My Documents" directory is used to keep the
user data which was kept in user home[1]. In the ways how programs
treat "HOME" and "My Documents", it says "In other programs, the home
folder is ignored, regardless of whether the home folder contains any
files." This is a proof that the HOME directory is not encouraged to
use any more. But it is still there. In windows Vista and 7, "My
Documents" directory is becoming a virtual directory, it is seen from
constant CSIDL_MYDOCUMENTS. It was CSIDL_PERSONAL in XP which is a
real directory[4].
Since windows XP, there is a user profile directory[2, 3]. It is
default to "C:\Documents and Settings\username" in XP and
"C:\Users\username" in vista and 7. User profile directory is
available as environment variable "USERPROFILE"; it is available in
Java by System.getenv("USERPROFILE"). USERPROFILE can be modified by
resetting the variable. And it is available through shell function
SHGetFolderLocation which is NOT affected by resetting the
"USERPROFILE " variable.
"Shell Folders" and shell functions
This is totally from this artical[5]. "Shell Folders" registry key is
a mistake in windows 95. When "roaming profile" is considered, it is
decided to use function "SHGetSpecialFolderLocation" to get the
folders represented in "Shell Folders". However, the key is kept as a
shadow. And function SHGetFolderLocation is suggest to replace
function SHGetSpecialFolderLocation in XP[6].
So, the home directory reported by registry is a shadow of the value
from shell API, I think the difference is caused by missed update.
Detail to Java's implementation, there might be another difference:
windows supports changing the location of "Desktop" directory, and
Java takes the parent of "Desktop" from registry, this is not tested.
The "USERPROFILE" is an environment variable which is set to the
profile directory report by shell API, but it can be reset.
Applications' default paths
"cmd" is using profile directory as default path even "HOME" is set to
other directory. Login through telnet will use "HOME" directory as the
default, but Java is not using this "HOME" as user.home, it still uses
the profile shadow in registry. But I don't have an environment to
test domain users. I think the shell function mentions roaming
profile, it should handle.
[1]
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_homedir.mspx?mfr=true
[2]
http://msdn.microsoft.com/en-us/library/windows/desktop/bb776896(v=vs.85).aspx
[3] Shell contant CSIDL_PROFILE is available from version5.0 which is
windows 2000 or ME. So the profile directory might be available since
windows 2000 before XP.
[4]
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx
[5] http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx
[6]
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762203(v=vs.85).aspx
[7]
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_profile_homedirectory.mspx?mfr=true
============================================================
So in my understanding, the "HOME" directory is obsolete since XP, and
"My Documents" is a substitution. And the important thing is, the
directory represented by "HOME" is not a user's home compared with
Unix. User's home contains application data, user data, Desktop and
others. In windows, the USERPROFILE directory is much more similar to
act as a user home. And the current implementation is using the user
profile directory(the parent directory of Desktop, which is the
profile directory by default settings).
About the modified in webrev, I think it is just removing an old hack
which is obsoleted since win95.
On Fri, Oct 19, 2012 at 5:51 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
On 19/10/2012 10:11, Sean Chou wrote:
Hi all,
This is a fix for 651912. The fix removed the code to read
user.home from registry and get profile directory instead of the
parent of desktop directory. As suggested in
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx from
the bug page.
Bug: bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519127
Webrev: http://cr.openjdk.java.net/~zhouyx/6519127/webrev.00/
Please take a look.
Sean - any changes to the value of user.home has the potential to cause
issues, this is an area whether there has been a lot of ambiguity in past as
to where the user's home directory is, particularly with non-standard
configurations. 6519127 and several others have been waiting for a brave
person to re-examine this issue.
Do you think you could provide a detailed write-up on this topic? I think we
need to understand how the home directory, as reported by the shell API,
might differ to the value that the registry reports, also USERPROFILE. In
addition we've had so many issues over the years with different
configurations, Windows Terminal Server, local accounts vs. accounts in the
domain, etc. and I think we need to understand as much as possible as what
might change. Sorry there is lot more work here than you might have expected
but this is an area where we have to be very careful.
-Alan
