-
Bug
-
Resolution: Fixed
-
P2
-
5.0
-
b56
-
x86
-
windows_nt, windows_2000, windows_xp
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
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
- duplicates
-
JDK-5065874 regression: JFileChooser stalls accessing desktop shortcut
- Closed
-
JDK-5050925 JFileChooser is unlike native windows in Handling stale shortcuts
- Closed
-
JDK-5056514 REGRESSION: JFileChooser initialization complains and crashes VM
- Closed
-
JDK-5061941 Links to missing resources on desktop cause JFileChooser to popup error messages
- Closed
- relates to
-
JDK-4356160 JFileChooser doesn't support shortcuts (.lnk files)
- Resolved
-
JDK-5055740 REGRESSION: JFileChooser: pif files show up as dirs and cause InternalError
- Resolved
(1 relates to)