I did a bit more digging. I can reproduce this every time on my machine if:
1) I open cmd from total commander (64 bit or 32 bit, doesn't matter);
2) from that cmd run the simple example in Java that attempts to
resolve real path; this ends in InternalError.
On the other hand, if I run cmd from the start menu, everything works
fine. total commander is clean
(checked md5 to rule out viruses or whatever).
I have no idea what this is -- I think the problem can be marked as
"non-reproducible", maybe it's a glitch in my system somewhere. Sorry
for the noise.
Dawid
On Tue, Mar 15, 2016 at 1:56 PM, Rory O'Donnell
<rory.odonn...@oracle.com> wrote:
> Hi Dawid,
>
> I will update bug.
>
> Rgds,Rory
>
>
> On 15/03/2016 12:53, Dawid Weiss wrote:
>>
>> This must be more complicated than I thought because the same code
>> passes with flying colors on another (fairly fresh install) of Windows
>> 10... I don't know what the difference is, to be honest (I have
>> Windows 10 Pro N). I'll try to dig deeper, time permitting, but
>> perhaps a comment on the eventual Jira issue would be sensible (can't
>> do it myself, no Jira access).
>>
>> Dawid
>>
>> On Tue, Mar 15, 2016 at 1:01 PM, Dawid Weiss <dawid.we...@gmail.com>
>> wrote:
>>>
>>> I filed an issue (Review ID: JI-9032181). In any case, I checked with
>>> Java 7, 8 and the ea:
>>>
>>> Java(TM) SE Runtime Environment (build
>>> 9-ea+109-2016-03-09-181019.javare.4620.nc)
>>>
>>> The issue only affects Windows 10 (tested on 64-bit only), Windows 7
>>> behaves fine. The following sequence is enough to get the stack trace:
>>>
>>> mkdir foo
>>> mklink /J bar foo
>>> java -cp . Test bar
>>>
>>> The Test.java code is:
>>> import java.io.*;
>>> import java.nio.file.*;
>>>
>>> public class Test {
>>> public static void main(String[] args) throws Exception {
>>> Path p = Paths.get(args[0]);
>>> System.out.println("p.toRealPath(): " + p.toRealPath());
>>> }
>>> }
>>>
>>> and the stack trace:
>>>
>>> Exception in thread "main" java.lang.InternalError: Should not get here
>>> at
>>> sun.nio.fs.WindowsNativeDispatcher.GetFinalPathNameByHandle(Native
>>> Method)
>>> at
>>> sun.nio.fs.WindowsLinkSupport.getFinalPath(WindowsLinkSupport.java:77)
>>> at
>>> sun.nio.fs.WindowsLinkSupport.getRealPath(WindowsLinkSupport.java:242)
>>> at sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:840)
>>> at sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:44)
>>> at Test.main(Test.java:10)
>>>
>>> Dawid
>>>
>>> On Tue, Mar 15, 2016 at 12:28 PM, Alan Bateman <alan.bate...@oracle.com>
>>> wrote:
>>>>
>>>> On 15/03/2016 11:19, Dawid Weiss wrote:
>>>>>
>>>>> I couldn't find an appropriate bug in bugzilla, but this fails
>>>>> reliably for me with Java 8 and 9 on Windows 10, 64-bit:
>>>>>
>>>>> mkdir foo
>>>>> mklink /J bar foo
>>>>> cd bar
>>>>> java -cp Test .
>>>>>
>>>>> where Test.java is as simple as:
>>>>>
>>>>> import java.io.*;
>>>>> import java.nio.file.*;
>>>>>
>>>>> public class Test {
>>>>> public static void main(String[] args) throws Exception {
>>>>> System.out.println("p.toRealPath(): " +
>>>>> Paths.get(args[0]).toRealPath());
>>>>> }
>>>>> }
>>>>>
>>>>> The thrown error shows:
>>>>>
>>>>> Exception in thread "main" java.lang.InternalError: Should not get here
>>>>> at
>>>>> sun.nio.fs.WindowsNativeDispatcher.GetFinalPathNameByHandle(Native
>>>>> Method)
>>>>
>>>> There are a number of win32 functions that this code uses GetProcAddress
>>>> to
>>>> get their address in kernel32. This dates back to when we had to support
>>>> Windows XP. This should be cleaned up now. Doesn't explain why you are
>>>> seeing though, can you submit a bug?
>>>>
>>>> -Alan
>
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
