JDK-6607535 : Please support FILE_SHARE_DELETE flag in RandomAccessFile constructor
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 7
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-09-21
  • Updated: 2011-02-16
  • Resolved: 2007-09-21
Related Reports
Relates :  
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 ----------

Comments
EVALUATION The suggestion to change the sharing mode is RFE 6357433. It would be great to do that but it may break existing applications (since the current behavior has existed since jdk1.0). Adding a special mode to RandomAccessFile to work around a Windows issues is probably not the right approach either. Also, there is some suggestion that this can help with the issue of deleting files that have a file mapping. This is not so, as a file mapping still prevents a file from being deleted. Anyway, for jdk7 we are working on a new file system API that will address some of the requirements here. The Windows implementation does the right thing so that opened files can be deleted. Also, it has support for links.
21-09-2007