Review request: JDK-6519127 Vista: user.home property not set correctly

[Alexey Utkin]

Hi Anthony,

The MS back porting process is not trivial.
[SHGetKnownFolderPath] could be introduced is service pack for earlier OS.
In my opinion that is better to use the function based on fact of 
present (here the question is more about
Shell32.dll version, not OS version but they are in relation).

Alan, that do you think about it?

Regards,
-uta


On 22.01.2013 19:45, Anthony Petrov wrote:
> Hi Alexey,
>
> The fix looks good from code logic perspective.
>
> I'm only concerned with whether we should use the __try/__except 
> magic, or would it rather make sense to define:
>
> #define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) >= 6)
>
> and guard the call to SHGetKnownFolderPath() with this check? This 
> seems to be lighter than using the exception handling machinery from 
> performance perspective, and IMO it would make the code cleaner/easier 
> to read.
>
> -- 
> best regards,
> Anthony
>
> On 1/22/2013 19:30, Alexey Utkin wrote:
>> On 22.01.2013 16:52, Alan Bateman wrote:
>>> On 22/01/2013 12:28, Alexey Utkin wrote:
>>>> To be clear, there are three options for a shell call:
>>>>     1. Force folder creation if not exists (KF_FLAG_CREATE)
>>>>     2. Return existent folder if any (0)
>>>>     3. Return folder name without verification (KF_FLAG_DONT_VERIFY)
>>>>
>>>> Current implementation is close to the last option (without 
>>>> verification).
>>>> That is our choice for the fix? (My choice was #1)
>>>>
>>>> Regards,
>>>> -uta
>>> The JDK doesn't strictly require the user's home directory to exist 
>>> and it's possible in some environments for the home directory to 
>>> become inaccessible during the lifetime of the VM. The main thing (I 
>>> think) is that exceptions and messages are clear if there is an 
>>> error accessing something in the home directory.
>>>
>>> So I think #3 is the right answer. As you point out, this is 
>>> essentially long standing behavior. My concern with #2 is that it 
>>> might hurt startup significantly when the home directory is remote. 
>>> My concern with #1 is that I don't think the JDK should be the one 
>>> to create the home directory (although in practice it would be very 
>>> rare).
>> Sounds reasonable.
>> Let's follow that way. The #3 option is chosen.
>> Suggested fix:
>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.03/
>>
>> Regards,
>> -uta
>
>