Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4712781

1.4.0 REGRESSION: JFileChooser deletes user files unintentionally

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      03
    • CPU:
      generic, sparc
    • OS:
      generic, solaris_8

      Backports

        Description

        When editing a filename in JFileChooser, and then selecting
        a different file, the second file is renamed to the name
        of the first file, thereby deleting it.

        1. JFileChooser should apply the rename to the file whose
           name is being edited.

        2. JFileChooser should not allow renaming a file to a name
           that already exists.

        3. (rfe) A system property to disable the renaming functionality
           would be useful.

        ###@###.### 2002-07-10


        Clarification:

        There are two interrelated bugs that cause this to be very serious:

        1. When editing a file name and clicking on a different file without
           hitting Enter first, the name in the text field is *sometimes*
           applied to the wrong file. Note that this is intermittent due to
           race conditions and may happen on all platforms in both Metal and
           Windows L&F.

        2. When renaming a file to a name that already exists, the existing
           file is replaced, i.e. deleted. This is equivalent to the use of
           the "mv" command on Unix, and does not happen on Windows platforms.
           This difference in behavior is due to the platform dependent
           implementation of the method File.renameTo().


        To reproduce the combination bug, follow these steps on a Unix system:

        1. Create two or three junk files in a temporary directory.

        2. Run FileChooserDemo or SwingSet2 and bring up the filechooser.

        3. Select one of the files.

        4. Select the file again to start editing the name, but don't type
           anything.

        5. Select a different file.

        If nothing happens try steps 3-5 repeatedly. You may need to try on
        slower systems to reproduce the bug, or maybe try a remote X display.
        I was able to reproduce by displaying the CDE desktop on a PC using
        VNC.

        NOTE: It is imperative to find a reproducing environment to be able to
        verify the fix for this bug.


        Original user bug report
        ------------------------

        Date: Tue, 2 Jul 2002 22:01:08 -0400

        release: 1.4
        hardware: sun4
        OSversion: sol2.8
        priority: 4
        synopsis: JFileChooser deletes files by accident!!
        description: FULL PRODUCT VERSION :
        java version "1.4.0"
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
        Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
        FULL OPERATING SYSTEM VERSION : SunOS 5.8 Generic_108528-11
        sun4u sparc SUNW,Sun-Blade-1000

        A DESCRIPTION OF THE PROBLEM :
        This happens on Solaris 8.
        I create and show a JFileChooser.
        I click on a file (let's call it 'fileA') so as to make the title
        editable.
        I then click on the file directly above it or directly below it (let's
        call it 'fileB').

        The file I just clicked (fileB) disappears!!

        No trace whatsoever of the file, either in the JFileChooser, or by
        doing ls command in the directory. Scary stuff!!!
        Note that I did not click again on 'fileA' to make the title
        non-editable.

        I made fileA's title editable (as though I am going to change the
        title),

        and then I immediately click on fileB, and fileB disappears!!

        I am too scared to try this on a directory. I'm afraid my whole
        filesystem will disappear!
        REGRESSION. Last worked in version 1.3.1
        REPRODUCIBILITY :
        This bug can be reproduced always.
        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        (Don't do this in any directory that you need!!!)
        1. Display a JFileChooser on the screen.
        2. Go to a directory in which there is at least 2 files.
        3. Make sure that you don't need these files.
        4. Make sure that you don't need these files!!!
        5. Click on a file in the directory so that it is selected.
        6. Click on the same file again, so as to put the title in
        an editable state.
        7. Without putting the title of the file in a non-editable
          state, click on another file in the directory.
        8. Cry, because JFileChooser has just deleted your file.

        ---------- BEGIN SOURCE ----------
        import javax.swing.*;
        import javax.swing.event.*;
        import java.awt.*;
        import java.awt.event.*;
        // Try this on Solaris 8
        // Or should I say DON'T TRY THIS
        public class ThankGodForBackup
        {
           public static void main( String [] args )
           {
              JFileChooser evilFileChooser = new JFileChooser(".");
              evilFileChooser.showOpenDialog(null);
              // Do as stated above.
              // Go in a corner and cry.
           }
        }

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        The expected result is that when you click on fileB without
        putting fileA's title in a non-editable state, fileB should
        still be there.
        However the actual result is that when you click on fileB
        without putting fileA's title in a non-editable state,
        fileB disappears.
        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        Absolutely nothing.

        ###@###.### 2002-07-11

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                leifs Leif Samuelsson (Inactive)
                Reporter:
                leifs Leif Samuelsson (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: