RFR(S) 8190737: use unicode version of the canonicalize() function to handle long path on windows

[Calvin Cheung]

Thanks, Ioi.

Calvin

On 9/13/18, 4:06 PM, Ioi Lam wrote:
> Looks good. Thanks!
>
> Ioi
>
>> On Sep 10, 2018, at 11:42 AM, Calvin Cheung<calvin.cheung at oracle.com>  wrote:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
>>
>> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
>>
>> Please review this change for handling long path specified in the -Xbootclasspath/a on windows.
>>
>> Highlight of changes:
>> - canonicalize_md.c
>>     it makes use of the unicode version of canonicalize (wcanonicalize) if the original path is>= MAX_PATH.
>>
>> - zip_util.c
>>     it uses the unicode version of CreateFile (CreateFileW) if the original path is>= MAX_PATH.
>>
>> - io_util_md.c
>>     Since zip_util.c (libzip) calls the getPrefixed() function in canonicalize_md.c (libjava), the getPrefixed() function needs to be exported.
>>
>> - java_md.h
>>     The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It is because the the current usage of the canonicalize() function from vm code is to preallocate the output buffer as follows:
>>             char* canonical_path = NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN);
>>             if (!get_canonical_path(path, canonical_path, JVM_MAXPATHLEN)) {
>>     Also the unix version of canonicalize() function has the following check:
>>             int
>>            canonicalize(char *original, char *resolved, int len)
>>            {
>>                if (len<  PATH_MAX) {
>>                errno = EINVAL;
>>                return -1;
>>            }
>>    So dynamically allocating the output buffer requires more work beyond the scope of this change.
>>
>> - LongBCP.java
>>     added a scenario to the test - a long path to a jar file in -Xbootclasspath/a.
>>
>> Testing: tier-[1,2,3].
>>
>> thanks,
>> Calvin