United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7012783 JFileChooser fails to resolve DFS links on Windows Vista SP2
JDK-7012783 : JFileChooser fails to resolve DFS links on Windows Vista SP2

Details
Type:
Bug
Submit Date:
2011-01-17
Status:
Resolved
Updated Date:
2011-09-07
Project Name:
JDK
Resolved Date:
2011-05-31
Component:
client-libs
OS:
windows_vista,windows_7
Sub-Component:
javax.swing
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u23,6u24,7
Fixed Versions:
6u26-rev (b22)

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

Description
DFS links in DFS shares cannot be resolved with javax.swing.JFileChooser 
class of Java SE 6 on Windows Vista SP2: the link cannot be opened.
The behavior is strictly reproducible.
Windows Vista SP2 Explorer however opens that type of links just fine
and shows the contents of the directory opened.

Windows Vista SP1 Explorer obviously cannot handle DFS links at all, and 
issues the following error message: 'Z:\DFSLINK is not accessible'.

JFileChooser on Windows 7 behaves just like on Windows Vista SP2.

                                    

Comments
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.
                                     
2011-03-07



Hardware and Software, Engineered to Work Together