On Mon, 2009-11-09 at 00:28 -0500, Alex wrote: > >> I'm a bit disappointed that I > >> can't do it by overriding the server command line > > > > Why? Does it have some advantage over the use of an rsync daemon (I > > can't imagine what)? One can't really expect overriding the server > > arguments not to lead to the inconsistent behavior you saw. > > Simplicity. I'd like to be able to have the server side feed me all > data beginning with the path I specify, such /backup/serverA,
In other words, you were specifying a bogus source path and counting on sshd to override it with the real one. Clever. I didn't catch that the first time. Realize that the ability to set a module's "path" in the rsyncd.conf file and have the client refer to the module by a well-known name gives you the same functionality, and actually more, because the client can specify a subdirectory path within the module. > and have > the client side be able to "--include=/usr/bin" to be able to > 'download' only the data from /backup/serverA/usr/bin and exclude > everything else. That --include means "exclude everything else" is a common misconception; see the man page. But I imagine the issue will become moot if you have the client specify a subdirectory of the module instead of using filters. > Instead, I have about eight sections of my rsyncd.conf to do this; one > for each directory tree that I want to back up to a different > location, primarily based on dates, to have multiple incrementals. If the daemon solution is looking fundamentally more complicated than the set of forced server commands you previously had, you're probably going about it the wrong way and I could help if you post the rsyncd.conf file. -- Matt -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
