Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 5036327
Votes 2
Synopsis File should support consistent, cross-platform file delete and rename mechanism
Category java:classes_io
Reported Against 1.4.2
Release Fixed
State 11-Closed, duplicate of 4313887, request for enhancement
Priority: 4-Low
Related Bugs
Submit Date 22-APR-2004
Description


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) 
======================================================================
Posted Date : 2005-08-25 19:31:45.0
Work Around
N/A
Evaluation
Something to look at for the nio2 JSR.
  xxxxx@xxxxx   2004-04-22
This feature has been addressed by the new file system API defined by JSR-203.
Posted Date : 2009-02-16 13:50:34.0
Comments
  
  Include a link with my name & email   

Submitted On 05-JUN-2005
ecki
Please use a FileNotFound Excetion on delete in order to allow it to  be ignored (i.e. i want to know atomically if the file vanished no matter if it was deleted before me or if my delete suceeded)

Same is true for rename, one really needs to know what failed (file not presetn, target not resent, file locked/used or permission denied.)



PLEASE NOTE: JDK6 is formerly known as Project Mustang