Java process.waitFor() does not return

Question

On Windows 7 64 bit, running 64 bit Java 1.7.0_17 , the p.waitFor() shown below never returns.

String move_command="cmd.exe /c xcopy /Y /E "+x86_release+" "+path+"\\";
Process p;
p = Runtime.getRuntime().exec(move_command);
p.waitFor();

If I use Windows Explorer, it looks like all the files are copied (same number, same size, etc.)

If I do the below, it waitFor() does return:

String move_command="cmd.exe /c move /Y "+x86_release+" "+path+"\\";
Process p;
p = Runtime.getRuntime().exec(move_command);
p.waitFor();

What could be so different between an xcopy and a move that keeps waitFor() from returning, or am I on the wrong track entirely?

Answer 1

I suspect you're not consuming the process standard out/err, and that's blocking the process. If your code doesn't consume this output, then the spawned process will hang (and you'll hang waiting for that process!). Why the difference in behaviour between the two commands ? Probably due to the quantity of data returned and the impact on the publishing buffers.

See this answer for more details.

I would also investigate Apache Commons FileUtils.copyDirectory() such that you don't have to spawn a whole new process to copy files.

Answer 2

xcopy probably just happens to produce more output than move , filling up the out-buffer and blocking until it is flushed. The default behavior in Java is to pipe the subprocess's stdout/stderr into InputStream s that you are then required to read programmatically lest the subprocess's buffers overflow.

If the latter is the case, the solution is simple, and in fact you should do that anyway: use ProcessBuilder to prepare the system call and call inheritIO on it. This will reuse your parent process`s stdin and stdout for the subprocess.

A side note, xcopy is a regular .exe file and doesn't need wrapping into cmd.exe /c .