I'm glad it's working. I wonder what was going on on the destination that could be fixed with a reboot... but on a production environment, sometimes root cause analysis is a luxury you just can't afford.
I agree. You *are* using the single-colon syntax, but you've also brought up your rsyncd.conf, and are using the -p option. Maybe rsync should have complained about the wrong options, rather than just going ahead and working. There has been some discussion about having rsync refuse to run, rather than just silently ignoring meaningless options. It's low priority work, though. Yes, you CAN rsync to a system that isn't running an rsync daemon. In fact, that is the most common mode. As the maintainers explain: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Once installed you can use rsync to any machine that you can use rsh to. rsync uses rsh for its communications, unless both the source and destination are local. You can also specify an alternative to rsh, either by using the -e command line option, or by setting the RSYNC_RSH environment variable. One common substitute is to use ssh, which offers a high degree of security. SunOS 5.7 Last change: 25 Jan 2002 2 User Commands rsync(1) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some have used ssh to set up port forwarding to the rsyncd, so that the restrictions on the remote end rsyncd can be used inside the ssh transport, but that's external stuff, not part of the actual program. Tim Conway [EMAIL PROTECTED] 303.682.4917 office, 303.921.0301 cell Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, caesupport2 on AIM "There are some who call me.... Tim?" "Mack, Daemian" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/29/2002 12:03 PM To: Tim Conway/LMT/SC/PHILIPS@AMEC "Mack, Daemian" <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: RE: rsync: push_dir TESTDIR: No such file or directory Classification: > Daemian: You're mixing two mutually-exclusive modes - rsync > over ssh, and > rsync over rsync internal TCP transport to an rsyncd. -e ssh > is ignored > on rsync to rsyncd, and rsync to rsyncd requires the > double-colon("::") > representation of the remote. The --port= is also relevant only to > contacting an rsyncd. > In this case, you are opening an ssh stream, and passing info > over that, > to a shell. "[EMAIL PROTECTED]:TESTDIR" means > external transport to the subdirectory named "TESTDIR" under the > home directory of "MYUSERNAME" on machine "MY.SERV.ER.IP". I'm confused. I *am* using the single-colon, which, according to the man page, is the right way to specify "I want to use SSH for this operation," which I do. > So, your rsyncd.conf is also meaningless in this context. I'm starting to suspect that I can rsync to a machine that literally *does not have* rsync running in any sort of daemon capacity. Is this accurate? > Looking at it from the purpose of successfully doing what > your command > does, I'd first try > ssh MY.SERV.ER.IP <-l MYUSERNAME> pwd > and see if it's what you expect. You might be landing in a directory > where you don't have write perms... It's happenned. I have tried this, and am landing right where I expect to, in my remote home directory. The directory I'm specifying to sync with is present and is me-writable. In any case, it's working today. The only change I've made is to reboot the rsync server for an unrelated issue. I don't know what changed to make it start working, but at least it is. ;) Thanks for the pointers! Daemian Mack -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html