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