RFR: 6519127 : user.home property not set correctly

[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.Bateman at 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



-- 
Best Regards,
Sean Chou