JDK-7012783 : JFileChooser fails to resolve DFS links on Windows Vista SP2
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u23,6u24,7
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_vista,windows_7
  • CPU: x86
  • Submitted: 2011-01-17
  • Updated: 2014-08-21
  • Resolved: 2011-05-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u26-rev b22Fixed 7u2Fixed 8Fixed
Related Reports
Duplicate :  
JDK-7033126 - JFilechooser silent failure with DFS on Windows Server and Vista SP2
Relates :  
JDK-6852953 - JFilechooser silent failure with DFS on Windows Server and Vista SP2
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.
07-03-2011