JDK-4153564 : Win32 Runtime.exec() inherits fds; Solaris Runtime.exec() doesn't
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 1998-06-30
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.2.0 1.2fcsFixed
Related Reports
Relates :  
Relates :  
Description
If a Java VM opens a RandomAccessFile, spawns a subprocess (via Runtime.exec()),
closes the RandomAccessFile, and deletes the associated File, the delete will
fail on Windows NT.

The reason for this is that the file handle is inherited by the subprocess,
which has no way of accessing that file handle; consequently the subprocess
has no way to close the handle and must keep it open.  The file is marked as
in-use and undeleteable until the subprocess exits.

Here is a simple test (the parent waits for 30 seconds to let the child startup).

import java.io.*;

public class Shug
{
    public static void main(String[] argv)
	throws Exception
    {
	boolean child = (argv.length == 1);
	System.err.println((child ? "Child" : "Parent") + " starting");

	if (!child) {
	    // parent
	    File f = new File("foo");
	    RandomAccessFile log = new RandomAccessFile(f, "rw");
	    System.err.println("Parent opened log file");
	    System.err.println("Parent spawning child");
	    Process p = Runtime.getRuntime().exec(
						  new String[] {
						      "java",
						      "Shug",
						      "child"
						  });
	    System.err.println("Parent spawned child");
	    log.close();
	    System.err.println("Parent closed file; sleep 30");
	    Thread.sleep(30 * 1000);
	    System.err.println("Parent removing file");
	    if (f.delete())
		System.err.println("Delete succeeded.");
	    else
		System.err.println("Delete failed.");

	    System.err.println("Parent exiting");
	    
	} else {
	    // child
	    // do nothing
	    Thread.sleep(180 * 1000);
	    System.err.println("Child exiting");
	}
    }
}

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2fcs INTEGRATED IN: 1.2fcs
14-06-2004

WORK AROUND Don't use Windows. :-)
11-06-2004

SUGGESTED FIX The optimal fix would be to track down all the file handles and mark them as non-inheritable inside Java_java_lang_Win32Process_create. An alternative would be to change sysOpen in win32/hpi/src/sys_api_md.c so that it created the file in non-inherited mode, but this would have to be repeated for all filehandle-like objects (such as sockets), and still runs the risk that JNI code will fail to follow the protocol.
11-06-2004

PUBLIC COMMENTS If a Java VM opens a RandomAccessFile, spawns a subprocess (via Runtime.exec()), closes the RandomAccessFile, and deletes the associated File, the delete will fail on Windows NT. The reason for this is that the file handle is inherited by the subprocess, which has no way of accessing that file handle; consequently the subprocess has no way to close the handle and must keep it open. The file is marked as in-use and undeleteable until the subprocess exits.
10-06-2004

EVALUATION The description is right. However the Java language Spec does not specify anything on this issue, all current behaviors (semantics) are allowed by the spec. There is already a bug filed on this issue, see 4109888. We are going to apply temporary fix for the problem. ###@###.### 1998-06-30
30-06-1998