JDK-4356160 : JFileChooser doesn't support shortcuts (.lnk files)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.0,1.4.2,1.4.2_02,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    linux,windows_nt,windows_2000,windows_xp linux,windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2000-07-25
  • Updated: 2005-11-03
  • Resolved: 2004-05-03
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 b50Fixed
Related Reports
Duplicate :  
JDK-4846402 - JFileChooser doesn't follow windows links
Duplicate :  
JDK-4921933 - JFileChooser cannot navigate into shortcuts to folders
Duplicate :  
JDK-4388129 - Requirements fo JFileChooser: better Maintenace of dirs/files
Relates :  
JDK-2151271 - REGRESSION :folder having ".lnk" in the name can not be opened by 5.0 and later versions
Relates :  
JDK-6354456 - JFileChooser doesn't support shortcuts to files (.lnk files)
Relates :  
JDK-5036922 - JFileChooser fix for shortcuts doesn't work on Windows 98.
Relates :  
JDK-6180936 - REGRESSION: JFileChooser not resolves NetworkNeighbourhood Links in 1.5.0
Relates :  
JDK-4125893 - FileSystem class to encapsulate the abilities and limitations of a platform
Relates :  
JDK-5049016 - REGRESSION: JFileChooser resolving Windows desktop shortcuts too eagerly
Relates :  
JDK-5102604 - JFileChooser: Linked dir (directory-shortcut) failing (dir w/target.lnk inside)
Relates :  
JDK-4313887 - New I/O: Improved filesystem interface
Description
Name: stC104175			Date: 07/25/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)


JFileChooser does not support MS Windows shortcuts.  Unlike the standard Windows
file choosers, it does not allow the user to follow Windows shortcuts while
browsing the file system.

(I think that shortcuts are a disgusting hack and really wish Windows had
symlinks, but since shortcuts are what it has and since native apps support
them, I think it is a bug for Swing not to do so as well.  You might consider
this an RFE, but based on how I expect that most people react to the current
behavior, I think it's a bug.)
(Review ID: 107541) 
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b50 tiger-beta2
14-06-2004
WORK AROUND Name: stC104175 Date: 07/25/2000 - Could detect user selection of a shortcut and bring up another JFileChooser starting at the appropriate place (if a directory) or load the actual file (if a file), but this would require parsing the shortcut file. Ick. - Alternatively, I'm told that the AWT equivalent works for shortcuts. ====================================================================== Note: The following workaround relies on the unsupported and undocumented package sun.awt.shell. This package is used by Sun's implementation of JFileChooser, but is not considered a required part of J2SE. This workaround assumes J2SDK/JRE 1.4 beta2 or fcs. It may not work with later versions. The workaround is to extend JFileChooser and override the method approveSelection(). This example only works for choosing a single file, not for choosing directories or multiple files. import java.io.*; import javax.swing.*; import sun.awt.shell.ShellFolder; public class LinkChooser extends JFileChooser { public void approveSelection() { if (File.separatorChar == '\\' && !isMultiSelectionEnabled() && getFileSelectionMode() == FILES_ONLY) { File selectedFile = getSelectedFile(); if (selectedFile.getPath().endsWith(".lnk")) { File linkedTo = null; try { linkedTo = ShellFolder.getShellFolder(selectedFile).getLinkLocation(); } catch (FileNotFoundException ignore) { } if (linkedTo != null) { if (linkedTo.isDirectory()) { setCurrentDirectory(linkedTo); return; } else if (!linkedTo.equals(selectedFile)) { setSelectedFile(linkedTo); } } } } super.approveSelection(); } public static void main(String[] args) { JFrame frame = new JFrame("FileChooser test"); frame.setVisible(true); JFileChooser chooser = new LinkChooser(); int returnVal = chooser.showOpenDialog(frame); switch (returnVal) { case APPROVE_OPTION: System.out.println("You chose to open this file: " + chooser.getSelectedFile().getName()); break; case CANCEL_OPTION: System.out.println("Cancelled"); break; case ERROR_OPTION: System.out.println("An error occurred"); break; } System.exit(0); } } leif.samuelsson@Eng 2001-07-30 ============================================================================= Note: The workaround is broken in 1.4.2 and 1.5 beta1. It will be working in 1.5 beta2 and possibly in a future update to 1.4.2. Also note that in 1.5 beta2 and later, the test for isDirectory() above will always be false, as this is now handled internally. ###@###.### 2004-04-27
27-04-2004
EVALUATION Should follow links for traversing folders only. Should not resolve links for returning to application. leif.samuelsson@Eng 2001-07-11 Implemented isLink() and getLinkLocation() in class sun.awt.shell.Win32ShellFolder. leif.samuelsson@Eng 2001-07-17 Too risky to complete this fix for merlin, because it would raise issues between the definitions of the methods File.isDirectory() vs. FileSystemView.isTraversable(), which in turn affects performance when sorting folders separately from files. A workaround using the class sun.awt.shell.ShellFolder is available for J2SDK/JRE 1.4. leif.samuelsson@Eng 2001-07-30 The workaround still works fine for me on Windows XP with 1.4.2 and 1.5.0 beta1. If someone can post a reproducible test case which fails, then we can open a new bug to fix ShellFolder for 1.5.0. Please include stack trace. Thanks. ###@###.### 2004-04-14 The planned fix is to only resolve and traverse shortcuts to directories. This means that when selecting FILES_ONLY or FILES_AND_DIRECTORIES we will only return LNK files that do not point to directories. These returned shortcuts will not be resolved. When selecting DIRECTORIES_ONLY or FILES_AND_DIRECTORIES, then shortcuts to directories will only be traversed, never returned by JFileChooser. This seems most consistent with Windows' own file and directory choosers. ###@###.### 2004-04-19 Clarifiaction: In FILE_AND_DIRECTORIES mode you will be able traverse shortcuts to directories but not select one to be returned by getSelectedFile(). Other shortcuts are returned as is. ###@###.### 2004-04-21 The workaround is broken in 1.4.2 because target paths are resolved relative to link's parent directory in getLinkLocation(). They should be resolved relative to the Desktop instead. This will be fixed as well. ###@###.### 2004-04-21 The initial fix will only work on Win200 and later versions. A new bug 5036922 has been filed to fix this for Windows 98. ###@###.### 2004-04-23
21-04-2004