JDK-5036327 : File should support consistent, cross-platform file delete and rename mechanism
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-04-22
  • Updated: 2009-02-16
  • Resolved: 2009-02-16
Related Reports
Duplicate :  
Description
Name: rmT116609			Date: 04/22/2004


A DESCRIPTION OF THE REQUEST :
The behaviour of File.delete() and File.renameTo() is platform specific.   This is detailed in bugs like:

java.io.File.renameTo has different semantics on Solaris and Win32
http://developer.java.sun.com/developer/bugParade/bugs/4017593.html

File.delete() doesn't work the same between Windows & Unix
http://developer.java.sun.com/developer/bugParade/bugs/4722539.html

In Win95 JDK 1.1.1, File.delete() fails to delete the file from disk
http://developer.java.sun.com/developer/bugParade/bugs/4045014.html

While the evaluation of the above bugs explain the impossibility of providing identical functionality for all platforms under all circumstances.  This RFE is to request an API that functions identically in pure-Java programs when executed on any platform.  In this context, a pure-Java program runs within a single aggregate, and uses no native code.

JUSTIFICATION :
Pure-Java programs should have access to an API to delete and rename files that functions identically across all platforms.  The absence of this feature definitely makes WORA harder to attain.

While not entirely trivial, it is relatively straight-forward to accomplish this RFE using a SecurityManager and changes to several classes in the java.io. package.  Currently this sort of change can only be made by Sun.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either change the methods in question (unlikely), or introduce new ones with new semantics.  I would definitely prefer that Unix semantics be emulated on Windows, but whatever the exact semantics, they should be detailed in the Javadoc.  Something like the following (plus some detailed explanations) seems reasonable:

/**
Delete this file, or throw an exception indicating the cause of failure.
The behaviour of this method, when this file is being accessed by native code or external processes, is platform specific.
@throws IOException if the file can't be deleted
@throws IllegalArgumentException if the file doesn't exist
*/
public void deleteFile() throws IOException;

/**
Rename this file, or throw an exception indicating the cause of failure.
The behaviour of this method, when this file is being accessed by native code or external processes, is platform specific.
@throws IOException if the file can't be renamed
@throws IllegalArgumentException if the file doesn't exist
*/
public void renameFileTo(File file) throws IOException;
ACTUAL -
see description

CUSTOMER SUBMITTED WORKAROUND :
It is sometimes possible to avoid this limitation by introducing and coding to an IO abstraction layer, rather than using the classes defined in the java.io package.  While it is relatively easy to enforce this approach with a SecurityManager, forcing third party software (components, libraries, tec...) to use such an abstraction layer can be difficult to impossible.
(Incident Review ID: 232848) 
======================================================================

Comments
EVALUATION This feature has been addressed by the new file system API defined by JSR-203.
16-02-2009

EVALUATION Something to look at for the nio2 JSR. ###@###.### 2004-04-22
22-04-2004