Name: gm110360 Date: 02/21/2002


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 :

Any Microsoft Windows 9x/ME/NT4/2000/XP platform


A DESCRIPTION OF THE PROBLEM :
On windowing platforms, users are often accustomed to having
deleted files placed in a special location where they may be
recovered at a later time if the deletion was erroneous.
Typically, these special locations are referred to as a
"Recycle Bin" or "Trashcan".

The implementation of the java.io.File.delete() and
java.io.File.deleteOnExit() methods (on the Windows
platform) simply delete the files without giving the user
the option of future recovery.

When run on a platform that supports this metaphor, the Java
implementation should also follow the metaphor.

I propose that java.io.File.delete() and
java.io.File.deleteOnExit() be deprecated and the following
methods introduced:

/**
* Deletes the file or directory denoted by this abstract
* pathname. If this pathname denotes a directory, then
* the directory must be empty in order to be deleted. If
* the immediate argument is <code>false</code>, and the
* operating system supports the concept of a trashcan
* (or recycle bin), the file or directory is moved to the
* trashcan. If the operating system does not support the
* trashcan metaphor, the file is deleted immediately. (It
* must be noted that the immediate argument is only a
* <em>request</em> to the underlying operating system; the
* operating system is free to disregard the request.)
*
* @param immediate if <code>true</code>, deletes the file
* immediately otherwise, the file is
* moved to the trashcan or recycle bin,
* if that metaphor is supported by the
* operation system.
* @return <code>true</code> if and only if the file or
* directory is successfully
* deleted; <code>false</code>
* otherwise
*
* @throws SecurityException
* If a security manager exists and its <code>{@link
* java.lang.SecurityManager#checkDelete}</code>
* method denies delete access to the file
*/
public boolean delete(boolean immediate) ...

/**
* Requests that the file or directory denoted by this
* abstract pathname be deleted when the virtual machine
* terminates. Deletion will be attempted only for normal
* termination of the virtual machine, as defined by the
* Java Language Specification (12.9).
*
* <p> Once deletion has been requested, it is not possible
* to cancel the request. This method should therefore be
* used with care.
*
* <p> If the immediate argument is <code>false</code>, and
* the operating system supports the concept of a trashcan
* (or recycle bin), the file or directory is moved to the
* trashcan. If the operating system does not support the
* trashcan metaphor, the file is deleted immediately. (It
* must be noted that the immediate argument is only a
* <em>request</em> to the underlying operating system; the
* operating system is free to disregard the request.)
*
* @param immediate if <code>true</code>, deletes the file
* immediately otherwise, the file is
* moved to the trashcan or recycle bin,
* if that metaphor is supported by the
* operation system.
*
* @throws SecurityException
* If a security manager exists and its
* <code>{@link java.lang.SecurityManager#checkDelete}</code>
* method denies delete access to the file
*/
public void deleteOnExit(boolean immediate) ...

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the code below (DeleteTest.java)
2. create a file called junkfile
3. execute DeleteTest on a MS Windows platform

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected:
junkfile is deleted, but can be recovered from the Recycle Bin

Actual:
The file "junkfile" is immediately deleted, even if the OS
provides a trashcan metaphor.


This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.*;

public class DeleteTest {

    public static void main(String args[]) {
File f = new File("junkfile");
f.delete();
    }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
There is no workaround that is not platform dependant.
(Review ID: 143151)
======================================================================