JDK-4264750 : JFileChooser - No Disk Dialog with RMISecurityManager
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.2.2,1.3.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_2000
  • CPU: x86
  • Submitted: 1999-08-23
  • Updated: 2000-10-26
  • Resolved: 2000-10-26
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
1.4.0 betaFixed
Related Reports
Relates :  
Description

Name: wl91122			Date: 08/23/99


A program that installs the RMISecurityManager gets a modal dialog
 "There is no disk in the drive. Please insert a disk into drive a:" when 
instantiating a JFileChooser. Similar to closed bug 4147513, except 
that it is new to 1.2.2, and depends on installation of the 
RMISecurityManager. Code follows:

public class TestFileChooser {
  public static void main(String[] args) {
    System.setSecurityManager(new java.rmi.RMISecurityManager());
    new javax.swing.JFileChooser();
  }
}
>java -version
java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)
>java -fullversion
java full version "JDK-1.2.2-W"

NT 4.0 tested with SP3 and SP4 showed same result.

Bug 4219204 is clearly related in some way, but it is listed as closed, 
duplicate of 4089199, which in turn is listed as closed and will not be 
fixed!  To reiterate, this bug is unique because

1) It is specific to the RMISecurityManager (non RMI programs work fine)
2) It is new to 1.2.2 (1.2.1 worked fine)
3) It is specific to instantiation of the JFileChooser
(Review ID: 85660) 
======================================================================

Name: krT82822			Date: 09/19/99


When running an application which requires a Security Manager, 
such as an application that uses RMI, the Windows 
"No Disk in drive - Abort/Retry/Ignore" dialog is displayed 
when an attempt is made to display a JFileChooser.

The following program demonstrates the problem. It must be used
with a policy file which grants all permissions, such as the 
following:

File "java.policy":

grant {
  permission java.security.AllPermission;
};


File "JFileChooserTest.java":

import javax.swing.*;

public class JFileChooserTest
{
    public static void main(String args[])
    {
        //
        // To use RMI we need to have a SecurityManager.
        // We will use the default SecurityManager for this 
        // example.
        // 
        System.setSecurityManager(new SecurityManager());

        //
        // Creating the chooser with different paths has no 
        // effect. We'll try to display the C: drive...
        //
        JFileChooser chooser = new JFileChooser("c:\\");
        
        chooser.showDialog(new JFrame(), null);
        
        System.exit(0);
    }
}

To run the program:

java -Djava.security.policy=file:.\java.policy JFileChooserTest


The "Abort/Retry/Ignore" dialog is displayed and locks the UI.
Once the dialog is dismissed, the JFileChooser is displayed.

It is not acceptable to expect users to have to dismiss such 
dialogs every time they want to browse/load/save a file.

Note: if the program is run with the installed default
java.policy file, the "Abort/Retry/Ignore" dialog is displayed 
but an exception is thrown (java.security.AccessControlException)
when the dialog is dismissed and the JFileChooser is not 
displayed.

This problem occurs on:
Platform: Win 95/98/NT 4.0(service pack 5)
JVM: 1.2.2 (with and without HotSpot 1.0.1), 1.3 beta
(Review ID: 95243)
======================================================================

Name: rlT66838			Date: 11/08/99


java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

On a Windows NT 4.0 machine that has an A: diskette drive:

1. Remove any diskette from drive A:
2. Compile the following Java 2 program using JDK 1.2.2:
3. Run it.
4. Notice that the first JFileChooser comes up without trouble.
5. Dismiss the chooser by pressing cancel.
6. The program then sets RMISecurityManager and tries again.
7. Notice that this time, JFileChooser attempts to access drive A:, and gets the
windows error dialog: "There is no disk in the drive. Please insert a disk into
drive A:."
8. If you press the Ignore button, the normal JFileChooser dialog comes up.

Here's the Java Source Code:

import java.io.File;
import java.rmi.*;
import javax.swing.*;

/**
 * Demonstrates a bug where setting a security manager on Windows NT 4.0 causes
 * JFileChooser to attempt to access drive A: when dialog is shown, causing
error dialog.
 */
public class ShowChooserBug
{
    public static void main(String[] args)
    {
        System.out.println("Make sure that you have no diskette in your A:
drive.");
        System.out.println("Try #1 will work just fine...");

        tryChooser();

        System.out.println("Now setting system security manager...");
        
        Object curSecMgr = System.getSecurityManager();
        try
        {
            if ((curSecMgr instanceof RMISecurityManager) == false)
                System.setSecurityManager(new RMISecurityManager());
        }
        catch (SecurityException ex)
        {
            ex.printStackTrace();
        }

        System.out.println("On Windows NT 4.0, our next try shows an evil dialog
if no diskette in A...");

        tryChooser();

        System.exit(0);
    }

    public static void tryChooser()
    {
   		JFileChooser jFileChooser = new JFileChooser();
        jFileChooser.showOpenDialog(JOptionPane.getRootFrame());
    }
}

This problem means that any program with an RMISecurityManager installed will
not operate properly.  If nothing else, can't you suppress the darn error
message unless the user actually tries to navigate to the A: drive via the UI?
This seems easy, and the current behavior looks very unprofessional in my
application.
(Review ID: 97617)
======================================================================

Name: krT82822			Date: 12/15/99


F:\JAVA\jdk1.2.2\bin>java.exe -version
java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

If you comment out line 11 and run this code the dialog box appears and works
fine.

Leave in line 11 and run this piece of code and before the file chooser appears
a dialog box appears saying that "There is no disk in drive.  Please insert a
disk into drive A:" and three buttons "Abort" "Retry" "Ignor".  One you have
dissmissed the error dialog box the file chooser works just fine.

1  import java.rmi.*;
2  import javax.swing.JFileChooser;
3
4  public class temp
5  {
6    public static void main(String args[])
7    {
8      if(System.getSecurityManager() == null)
9      {
10       System.out.println("getting a security manager");
11    	 System.setSecurityManager(new RMISecurityManager());
12     }
13
14     JFileChooser chooser = new JFileChooser();
15     chooser.setMultiSelectionEnabled(false);
16
17     int returnVal = chooser.showSaveDialog(null);
18
19     System.exit(1);
20   }
21 }
(Review ID: 99040)
======================================================================

Name: skT45625			Date: 05/16/2000


java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, symcjit)

JFileChooser try to access Drive A: on an NT4.0 machine when the
SecurityManager is present and the policy is set to all. If the SecurityManager
is not on then the JFileChooser dialog comes up normally. When it is on, a
Insert Disk in Drive A: abort/retry/ignore dialog comes up before JFileChooser
displays. Eventhought the initial directory is not set to drive A:. I actually
traced the problem to File.listRoots() that turns around and call the native
FileSystem.listRoots(). The problem thickens as that the behavior does not
appear on all our NT machines...

Here is a sample programs to illustrate

public class FileChooserTest
{
    public static void doThis( Frame f )
    {
      JFileChooser fc = new JFileChooser() ;
      int val = fc.showDialog( f, "Add" ) ;

      if ( val == JFileChooser.APPROVE_OPTION ) {
           System.out.println( "Selected " + fc.getSelectedFile() ) ;
      }
    }
    
    public static void main( String[] args )
    {
        // Start Security Manager
       if ( System.getSecurityManager() == null )
	    System.setSecurityManager( new java.rmi.RMISecurityManager() ) ;
	     
       final JFrame f = new JFrame() ;
	    
       JButton b = new JButton( "Hit Me!!" ) ;
        
       b.addActionListener( new AbstractAction()
        {
            public void actionPerformed( ActionEvent evt )
            {
                doThis( f ) ;
            }
        } ) ;
        
        f.getContentPane().add( "Center", b ) ;
        f.setSize( 300, 300 ) ;
        f.setVisible( true ) ;
     }
}
(Review ID: 104945)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: merlin-beta INTEGRATED IN: merlin-beta
14-06-2004

WORK AROUND Name: wl91122 Date: 08/23/99 None found ====================================================================== Name: rlT66838 Date: 11/08/99 None -- It's hard to imagine us shipping our application like this. (Review ID: 97617) ====================================================================== Name: skT45625 Date: 06/12/2000 The workaround is probably as before, ie create a new FileSystemView which implements listRoots() correctly and pass this in to the constructor to FileChooser. (Review ID: 106030) ======================================================================
11-06-2004

EVALUATION When running this test case, I get the same results as described in the "Comments" section of this report. At any rate, I don't see anything RMI-specific in this report except for the use of java.rmi.RMISecurityManager, which isn't really RMI-specific anyway in 1.2.2, because at that point, RMISecurityManager simply extends java.lang.SecurityManager, so any problems resulting from the use of RMISecurityManager are really problems resulting from the use of the default security manager too (see the second report in the "Description" for confirmation of this). I don't know much about how javax.swing.JFileChooser is supposed to function in the light of an installed security manager in 1.2.2, so I'm recategorizing this for the Swing people to diagnose. peter.jones@East 1999-10- It's true that this is not specific to RMI, but to the combination of a security manager plus the JFileChooser (if you set the security manager to sun.applet.AppletSecurity, the same problem occurs). Hitting control-break while the "No Disk" windows dialog is up shows a strack trace where the JFileChooser is trying to initialize it's roots: "main" prio=5 tid=0x771930 nid=0x113 initialized [0x6f000..0x6fc44] at java.io.Win32FileSystem.canonicalize(Native Method) at java.io.File.getCanonicalPath(File.java:441) at java.io.FilePermission$1.run(FilePermission.java:213) at java.security.AccessController.doPrivileged(Native Method) at java.io.FilePermission.init(FilePermission.java:207) at java.io.FilePermission.<init>(FilePermission.java:257) at java.lang.SecurityManager.checkRead(SecurityManager.java:896) at java.io.Win32FileSystem.access(Win32FileSystem.java:342) at java.io.Win32FileSystem.listRoots(Win32FileSystem.java:356) at java.io.File.listRoots(File.java:1118) at java.lang.reflect.Method.invoke(Native Method) at javax.swing.filechooser.WindowsFileSystemView.getRoots(FileSystemView.java:358) at javax.swing.plaf.metal.MetalFileChooserUI$DirectoryComboBoxModel.<init>(MetalFileChooserUI.java:831) at javax.swing.plaf.metal.MetalFileChooserUI.createDirectoryComboBoxModel(MetalFileChooserUI.java:814) at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:160) at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:102) at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:123) at javax.swing.JComponent.setUI(JComponent.java:326) at javax.swing.JFileChooser.updateUI(JFileChooser.java:1402) at javax.swing.JFileChooser.setup(JFileChooser.java:314) at javax.swing.JFileChooser.<init>(JFileChooser.java:289) at javax.swing.JFileChooser.<init>(JFileChooser.java:251) at TestFileChooser.main(TestFileChooser.java:9) It's not yet clear whether this is a java.io.Win32XX problem or a JFileChooser issue. amy.fowler@Eng 1999-11-12 Not reproducible in merlin-beta, provided the application has correct permissions set in the active policy. Fixed by fix to rfe 4290709. leif.samuelsson@Eng 2000-10-26
12-11-1999