A customer has pointed out on the java.net forums that opening a file on Windows using a FileInputStream causes other processes to be unable to delete the file. This is intended behavior as the code is currently written, as the sharing flags specified during the opening of the file are FILE_SHARE_READ and FILE_SHARE_WRITE. See io_util_md.c, fileOpen. However, Windows 2000 supplies a new flag, FILE_SHARE_DELETE, which allows another process to delete the file while it is still open. The customer would like to have this functionality available because they are parsing logs generated by another process and when the second process attempts to rotate its logs it can not delete the old log because the JVM has it open. There are really no convenient workarounds for this problem as all approaches ultimately involve using a FileInputStream at least briefly to get the current data from the log and if the target process attempts to delete the file while it is open it will be unable to do so.

The associated thread is
http://forums.java.net/jive/thread.jspa?threadID=2150&tstart=0
Posted Date : 2005-11-30 23:48:50.0

N/A

In the new file system API then (by default) the FILE_SHARE_DELETE sharing option is used so that the file can be deleted. We need to think through the compatability implications of adding this to FileInputStream/FileOutputStream/RandomAccessFile as there may be applications depending on current behavior.
Posted Date : 2009-04-28 08:13:06.0

This problem may be more serious that was described by the submitter. Our application (SIMAGIS, system of image processing and analysis) works with a lot of large files. We often need to have identical copies of the same file in different directories. For example, the single 100 MB color image may be processed by several algorithms or by several users, working inside their own "home" directories. To save time and disk space, we intensively use hardware links (supported by all modern Windows versions). Though Java API doesn't support hardware links, the necessary native method is very simple: it just calls CreateHardLink method (http://msdn2.microsoft.com/en-us/library/aa363860.aspx).

The problem is that opening a file by Java API, for example by RandomAccessFile, blocks not only deletion of this file, but also DELETION OF ALL HARDLINKS TO THE SAME FILE! It is very, very inconvenient. Sometimes there are tens of hardlinks to the single file, processed by different modules of the application or even by different applications. Processing may require opening large files for a long time, maybe, via file mapping. And it is enough to open ONE of hardlinks to the file by some module, and ALL hardlinks become blocked (for deletion and renaming) until the first hardlink will be closed (maybe, in garbage collector only, it file mapping was used). If another module needs to remove some temporaty directory, containing some hardlinks to necessary resources, then the attempt to remove may fail at any time, depending on another modules or Java applications that opens some of hardlinks at the same time. As a result, we are enforced to create very complicated deletion schemes, that periodically tries to remove all extra files (that may essentially slow down the application), and we still have no guarantees that all such garbage files will be deleted until the application end.

Please, set FILE_SHARE_DELETE flag while opening RandomAccessFile. It seems to be very easy correction, not violating existing contracts; moreover, behaviour of I/O system on Windows will become more similar to behaviour on Unix/Linux systems. But if you think that it may be dangerous for existing Windows-oriented Java applications, please add corresponding flag to the second argument of RandomAccessFile constructor. For example: new RandomAccessFile(fileName, "rD") could mean opening in FILE_SHARE_DELETE mode.

For jdk7, we are working on a new file system API that does support links (including creating hard links).  Also, the Windows implementation does the right thing with sharing so that opened files can be deleted (that is FILE_SHARE_DELETE is used).