JDK-6357433 : FileInputStream.open(String) should use FILE_SHARE_DELETE share flag (win)
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.2.0,1.2.2,1.3.0,1.3.1,1.4.2,7
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS:
    generic,windows_98,windows_nt,windows_2000 generic,windows_98,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 2005-11-30
  • Updated: 2011-05-13
Related Reports
Duplicate :  
Relates :  
Relates :  
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

WORK AROUND For jdk7, the workaround is to use new file system API. So instead of new FileInputStream(f) and new FileOutputStream(f), use f.toPath().newInputStream() and f.toPath().newOutputStream().

EVALUATION 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.