Problem calling rsync from java on OSX

[Drew Lippolt]

rsync and ajug lists,

been pulling my hair out on this one.

i have some java code which uses the Process object to spawn an rsync 
connection in --daemon mode.

the exact same command executes properly when run from outside java (i.e 
.on the command line) on osx.  it also executes correctly from within 
java on linux using a similar jdk (sun 1.4.1 vs sun 1.4.2 for osx)

here is example code:

/*****************************/

import java.net.*;
import java.io.*;

public class TestClass {

    public static void main(String[] args) {

    String cmd = "/Users/dlippolt/.azerup/rsync --daemon 
--config=/Users/dlippolt/.azerup/rsyncd.conf --port=2874";

    System.out.println(cmd);

    try {
            Process proc = Runtime.getRuntime().exec(cmd);
            System.out.println("DEBUG: Rsync Processvalue: " + 
proc.waitFor());

    } catch (Throwable t) {

        t.printStackTrace();

    }


    }

}

/*****************************/

java note:  it didn't make any difference if i connected to the std 
in/out/err using BufferedReaders so i left that code out for brevity.

java note:  when the BufferedReaders were connected to stdout/err, 
nothing was sent to either from rsync, just as when run in --daemon mode 
from the command line.

here is the output of above code on the command line:
 
 
$ java TestClass
/Users/dlippolt/.azerup/rsync --daemon 
--config=/Users/dlippolt/.azerup/rsyncd.conf --port=2874
DEBUG: Rsync Processvalue: 12



on osx, i was getting (code 12) errors on startup, which was odd, since 
thats an io protocol error (associated with things like trying to rsync 
a file bigger than the filesystem will allow).  the rsync process 
wouldn't actually ever come online, though it would write 2 lines of 
errors into the rsyncd.log file referenced in 
/Users/dlippolt/.azerup/rsyncd.conf... thereby proving that rsync was 
initializing to the point that it was finding/reading/parsing the 
command line argument --config correctly.

here are the errors i was getting on rsync 2.6.3:

2004/11/18 21:46:03 [12110] rsync: writefd_unbuffered failed to write 12 
bytes: phase "unknown" [receiver]: Bad file descriptor (9)
2004/11/18 21:46:03 [12110] rsync error: error in rsync protocol data 
stream (code 12) at io.c(909)

here are the errors i was getting on rsync 2.5.7:

2004/11/18 23:17:29 [20392] rsync: writefd_unbuffered failed to write 12 
bytes: phase "unknown": Bad file descriptor
2004/11/18 23:17:29 [20392] rsync error: error in rsync protocol data 
stream (code 12) at io.c(515)

based on this i think i can rule out an rsync version difference.

i couldn't figure out why i was getting a protocol error until i came to 
this part of the rsync manpage:

If standard input is a socket then rsync will assume that it  is
              being  run  via inetd, otherwise it will detach from the 
current
              terminal and become a background daemon.  The daemon  
will  read
              the  config  file (rsyncd.conf) on each connect made by a 
client
              and respond to requests accordingly.  See the 
rsyncd.conf(5) man
              page for more details.

so i theorize (after much hair pulling) that when run from java, stdin 
is being read as a socket from rsync's perspective, and assumes its 
running in inet mode.  now the errors make more sense since it assumes 
that an rsync client is connecting to it right now instead of merely 
running in daemon mode.

so the questions:

does the rsync list have any thoughts on how to run rsync in daemon mode 
out of java without resorting to things like jni.

can i force daemon mode, even if the rsync process thinks it should be 
running out of inet?

problem notes:

** setting/removing the following options had no effect:

--no-detach
--tempdir
--blocking-io
--no-blocking-io
-v

** i'm not including my rsyncd.conf since i know its correct (it runs 
fine on linux, and from command line on both linux/osx.... and the 
logfile is being identified)

** putting the rsync command into a separate shell script and calling 
the shell script from java had no effect.

** some random thoughts from others i've spoken to about this:

-- in an attempt to explain why it works under linux but not osx, 
possibly since in linux stdin is a pipe by default

-- the osx jvm is rather new, possibly buggy