I've created a simple patch that allows the user to specify '&<integer>' for the hostname which causes it to use that specified file-descriptor as an already connected socket so that a program can connect for rsync, pre-communicate and then exec rsync (the normal stdio model). The existing --rsh feature can perhaps just barely be used to do this if you bend over backwards, but this simplifies it. But this allows the connection to be made BEFORE even executing rsync rather than vice-versa. I've also updated the man page. I didn't know what else might need to be updated. I'll be glad to enhance it further if necessary
Created attachment 3116 [details] This patch implements the described feature This patch has be preliminarily tested. I will update if any issues are found while using in production.
You can make rsync effectively use an existing fd by passing an $RSYNC_CONNECT_PROG that refers to a program that shuttles data between its stdin/stdout and the desired fd. I'm not sure that it is worth adding the & syntax to the official rsync.
(In reply to comment #2) > You can make rsync effectively use an existing fd by passing an > $RSYNC_CONNECT_PROG that refers to a program that shuttles data between its > stdin/stdout and the desired fd. I'm not sure that it is worth adding the & > syntax to the official rsync. > I'm aware of that, but you have to have yet another process and have some application to do that for you rather than follow the usual stdio pattern (set up fd, fork/exec). This patch makes things more resource efficient.
I'm sorry for the noise as I try to get the summary right. I've changed my mind about this enhancement: I'm now in favor of it because the implementation is so simple and it would provide a slightly easier and better-performing way to embed rsync in other programs that already have a network connection, such as my continusync (if I ever finish it).
(In reply to comment #4) > it would provide a slightly easier and > better-performing way to embed rsync in other programs that already have a > network connection, such as my continusync (if I ever finish it). > That's exactly the situation I had too. I had an existing network connection and wanted to let rsync have the rest of the traffic. So I exec() rsync when I'm done talking to the other side (and he exec's it too). Thanx
I noticed that this was proposed a long time ago: http://lists.samba.org/archive/rsync/2003-March/005418.html It looks like JW Schultz was proposing treating a client with a supplied connection as a special kind of server with am_server set to a distinctive value. I don't think that approach will work now that the client/server distinction means many things besides whether to make a connection or use a provided one, so the current approach of just hooking the code that makes the connection is correct.