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

Please support FILE_SHARE_DELETE flag in RandomAccessFile constructor

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P5
    • Resolution: Won't Fix
    • Affects Version/s: 7
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_xp

      Description

      A DESCRIPTION OF THE REQUEST :
      On Windows platform, any opening a file by Java API blocks deletion not only this file, but also all hardware links to it. It leads to serious problems in our application (SIMAGIS) that creates and deletes a lot of hardlinks to large files, to save copy time and disk space. (Though Java API doesn't support hardware links, the necessary native method is very simple; besides, some components of our application are written in C++ and work with hardlinks via WinAPI.)

      The correct way of opening file in Windows, in most situations, is using FILE_SHARE_DELETE while opening file. Unfortunately, Java API does not support this. So, if Java application opens a file in any way, then all other applications and Java modules, working with hardlinks to this file, sometimes fails while attempts to remove extra hardlinks. As a result, we have a lot of non-removed "garbage" hardlinks and must develop complicated schemes for periodic cleaning them, that may strongly reduce the performance.

      Can you, please, add special flag to the 2nd argument of RandomAccessFile constructor, that turns on FILE_SHARE_DELETE opening mode? For example, "D": new RandomAccessFile(fileName, "rD") could open the file for reading in FILE_SHARE_DELETE mode. Our application is based on mapping large files, so we need this feature for RandomAccessFile and its FileChannel.

      The analogous request concerning FileInputStream is published here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6357433
      But unlike that submitter, we need FILE_SHARE_DELETE mode for RandomAccessFile only (for file mapping). So, I've decided to submit separate request. As I understand, adding new character flag to the RandomAccessFile constructor is a very simple and absolutely safe solution - maybe, unlike correction of the default behavior of Java I/O subsystem.

      JUSTIFICATION :
      Current Java I/O API, not supporting FILE_SHARE_DELETE, in fact, is incompatible with any applications that use hardware links on Windows platform. There are no ways to correctly manage hardlinks (create, rename, remove them) to the same file, if at least one of Windows applications, working with them, does not use FILE_SHARE_DELETE flag while opening them, even only for reading. Currently, Java applications are examples of such "bad" applications.




      ---------- BEGIN SOURCE ----------
      import java.io.*;
      public class Test {
          public static void main(String[] args) throws IOException {
              RandomAccessFile raf = new RandomAccessFile(args[0], "r");
              System.out.println("File opened");
              new BufferedReader(new InputStreamReader(System.in)).readLine();
              raf.close();
              System.out.println("File closed");
          }
      }

      Please create, by any suitable tool, two hardlinks at the same temporary file: "1.tmp" and "2.tmp". Please run the test for the first file: "java Test 1.tmp". It will print "File opened" and pause. At this moment, please try to rename or remove "2.tmp", for example, by Windows Explorer. You will see an error message, though "2.tmp" file seems to have no relation to "1.tmp".
      ---------- END SOURCE ----------

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                ndcosta Nelson Dcosta (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: