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

File should support consistent, cross-platform file delete and rename mechanism

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Duplicate
    • P4
    • None
    • 1.4.2
    • core-libs
    • x86
    • windows_xp

    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)
      ======================================================================

      Attachments

        Issue Links

          Activity

            People

              alanb Alan Bateman
              rmandalasunw Ranjith Mandala (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: