EVALUATION

After discussion with Pavel.

I believe the problem is in the following lines (see Z:\DFSLink section in Thomas's results):
shellFolder.isLink() = true
shellFolder.getLinkLocation() = null

That means that FileChooser cannot navigate to LinkLocation, because it's NULL. Take a look at the BasicFileChooserUI#changeDirectory method and the problem will be clear. Therefore the Win32ShellFolder2#getLinkLocation method should be fixed, which uses native getLinkLocation method (see the src\windows\native\sun\windows\ShellFolder2.cpp file for details)

Regards, Pavel 


----------------
Mail From Thomas.
 Here is the output requested, when navigating to 'DFSLINK' and trying
  to open it:

--------------------------------------------------------------------------
createShellFolderFromRelativePIDL parentC:\Users\Administrator\Documents
linkLocationPIDL ()=1020144
getDesktop ()=C:\Users\Administrator\Desktop
createShellFolderFromRelativePIDL parentC:\tl15687\FIDUCIA\subdir
location ()=C:\tl15687\FIDUCIA\subdir
linkLocationPIDL ()=0
getDesktop ()=C:\Users\Administrator\Desktop
location ()=null
--------------------------------------------------------------------------

My reply.

This does get resolved correctly as we can from your log as well.
-----
createShellFolderFromRelativePIDL parentC:\tl15687\FIDUCIA\subdir
location ()=C:\tl15687\FIDUCIA\subdir
-----
The native method does resolve the 'long' field passed as parent to the proper path (identical on my Xp machine.)

but the 2nd call is returning 0,
when I ran on my machine Xp the 2nd call gave me path to Acrord32.exe something like 
C:\program files.....\acrord32.32
I'm confused why the 2nd call happens and more importantly why if any that makes the difference.