JDK-5049016 : REGRESSION: JFileChooser resolving Windows desktop shortcuts too eagerly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-05-18
  • Updated: 2004-06-14
  • Resolved: 2004-06-14
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.
Other
5.0 b56Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
With recent tiger-beta2 buils (b50, b51) we're experiencing frequest error dialogs when opening JFileChooser (and derived components) on Windows XP systems. It seems that JFileChooser (or underlying java.io.* infrastructure) is trying to resolve Windows shortcuts (.lnk files) found on user's desktop. The problem occurs when there are broken shortcuts referring to non-existing file paths and removable media drives (possibly network drives too). Several different symptoms have been observed:

1. A system error message about unavailable link:

"The drive or network connection that the shortcut 'Some File.lnk' refers to is unavailable. Make sure that the disk is properly inserted or the network resource is available, and then try again."

2. A Missing Shortcut error dialog, windows searching to locate the file, followed by a Problem with Shortcut message:

"The item 'X:\' that this shortcut refers to has been changed or moved, so this shorcut will no longer work properly..."

3. "There is no disk in drive. Please insert a disk into drive X:."

The following simple test case can be used to reproduce the problem:

    public static void main(String[] args) {
        JFileChooser chooser = new JFileChooser();
        int returnVal = chooser.showOpenDialog(null);
        if(returnVal == JFileChooser.APPROVE_OPTION) {
           System.out.println("You chose to open this file: " +
                chooser.getSelectedFile().getName());
        }
    }

Please note that there must be at least invalid shortcut on the desktop to be able to reproduce the problem. Interestingly, native File Open/Save dialogs in Windows apps do not trigger such messages. It's a question why there should be any reason for Java FileChooser to examine the validity of shortcuts.

This is a new behavior in tiger-beta2. I suspect that it may be related to the recent fix of #4356160, but I'm not sure.

For more possibly related info see NetBeans bug #43314:
http://www.netbeans.org/issues/show_bug.cgi?id=43314

###@###.### 2004-05-18
###@###.### 2004-05-27

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-rc FIXED IN: tiger-rc INTEGRATED IN: tiger-b56 tiger-rc
08-07-2004

EVALUATION The native method Win32ShellFolder2.getLinkLocation() should not call IShellLink->Resolve(). ###@###.### 2004-05-18 Removed call to Resolve() and added caching of that fact that a link is invalid. This speeds up directory lookups because we don't have to keep following a link that is null. ###@###.### 2004-05-27
27-05-2004