Re: Synchronizing to multiple locations on a single destination s erve r
Steve Bonds wrote: > If the destination server is the same you should be able to copy the > files > over to one common directory and either symlink or hard-link them from > the > final destinations. > > For example, on the destination server: > > /opt/app-name/lib/: >contains all 4 libraries needed > > /opt/app1/lib/: >contains symlinks to /opt/app-name/lib/lib1.jar, > /opt/app-name/lib/lib2.jar, etc. > > If you want to avoid the mess of symlinks, you could just copy the files > from the /opt/app-name/lib area out to the respective individual > destinations-- avoiding the extra rsyncs. > > -- Steve > Hello Steve, thanks for the reply, but: I have already thought of a similar and is not an appropriate solution for me because of two reasons: 1. The target server is a cygwin running on Windows (with a Windows JVM), so symlinks are not an option. The only choice I have is probably phisically copying the files. 2. I would like to avoid an overhead of establishing the ssh connection twice (once for copying the files over and once for distributing the files to all the apropriate locations). Any other ideas? Thanks in advance, Bojan -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Prepping for a new release (2.5.8? 2.6.0?)
On Sun, Dec 14, 2003 at 11:32:07PM -0600, John Van Essen wrote: > would you care to take the bull by the horns and produce a release > candidate for 2.5.8 so that the rsync enthusiasts on the rsync mailing > list can give it a whirl prior to an official release (hopefully by > Christmas)? I was just about to say something about this on the list, so I'll do it in reply to your question: Yes, I'd like to get the CVS version finished up and a new release made. I'm currently reviewing a few old emails I had marked, and checking in some minor changes. Some questions for everyone: - What issues remain that need to be worked out before a new release? For instance, we should probably organize a security audit of the code changes for the new version (some auditing was done recently, but I'm not sure exactly how much). - What should we call the new version? I'm leaning towards 2.6.0 because of the new features (such as --files-from) and the various large changes (such as better check-summing, fixed include/exclude matching, etc.), but I could be talked into 2.5.8. If the remaining issues are small, I'll create a test release tarball in the next day or so, which will allow those adverse to CVS to help out in the pre-release testing. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [patch] New RC to differentiate partial xfers from files that get deleted before they're xfered
On Mon, Aug 25, 2003 at 05:56:54PM -0700, jw schultz wrote: > However, i'd rather not create the new global variable io_vanished. > Instead let's turn io_error into a bitmask. I just checked in some changes that implement the file-vanished warning (adding support for exit code 24 -- RERR_VANISHED) in this manner. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Rsyncing Windows directory to a Linux box: problem with spaces in directory names
Hello, I am trying to rsync folders/files hosted on a Windows machine to a Linux machine. Many of the directory names have spaces in them. How can I list them in a file so that the --include-from option use them correctly? Thanks! Charles -- Charles-E. Nadeau Ph.D http://radio.weblogs.com/0111823/ -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Prepping for a new release (2.5.8? 2.6.0?)
On Mon 15 Dec 2003, Wayne Davison wrote: > > Yes, I'd like to get the CVS version finished up and a new release made. Good to hear! > - What should we call the new version? I'm leaning towards 2.6.0 >because of the new features (such as --files-from) and the various >large changes (such as better check-summing, fixed include/exclude >matching, etc.), but I could be talked into 2.5.8. I'd agree with 2.6.0; there's also a protocol bump. > If the remaining issues are small, I'll create a test release tarball in > the next day or so, which will allow those adverse to CVS to help out in > the pre-release testing. I'll make debian packages of those... Paul Slootman -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: dg/ux --delete anomaly
> > On Sat, Dec 13, 2003 at 10:54:34AM -0500, Tim Boyer wrote: > > I'm running rsync 2.5.7 on Data General dg/ux 4.20, and just > noticed that > > the --delete command is not deleting. > > > > # />ls -la /test > > total 5 > > drwxr-xr-x 2 root other 512 Dec 13 10:46 . > > drwxr-xr-x 37 root root 1536 Dec 13 10:46 .. > > -rw-r--r-- 1 root other 0 Dec 13 10:46 a > > -rw-r--r-- 1 root other 0 Dec 13 10:46 b > > -rw-r--r-- 1 root other 0 Dec 13 10:46 c > > > > # />ls -la /test1 > > total 5 > > drwxr-xr-x 2 root other 512 Dec 13 10:47 . > > drwxr-xr-x 37 root root 1536 Dec 13 10:46 .. > > -rw-r--r-- 1 root other 0 Dec 13 10:46 d > > -rw-r--r-- 1 root other 0 Dec 13 10:46 e > > -rw-r--r-- 1 root other 0 Dec 13 10:47 f > > > > # />rsync -a --delete /test/* /test1 > > Unless you specify a directory it cannot delete. > Try that with > # />rsync -a --delete /test/ /test1 > instead > Sonofa... that works, of course. Thanks much. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Multiple streams/window sizing options ala BBFTP?
This must get asked all the time, but I didn't see any results from a search in the archive, so... Are there any plans to integrate features such as using configurable, multiple streams, or configurable window sizes? Something like BBFTP or GridFTP features would be nice - is anyone working on this? Rsync is much more feature-rich than either, but they do have a few nice features in terms of bandwidth management. Thanks, Jason -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Prepping for a new release (2.5.8? 2.6.0?)
On Mon, Dec 15, 2003 at 12:57:05AM -0800, Wayne Davison wrote: > On Sun, Dec 14, 2003 at 11:32:07PM -0600, John Van Essen wrote: > > would you care to take the bull by the horns and produce a release > > candidate for 2.5.8 so that the rsync enthusiasts on the rsync mailing > > list can give it a whirl prior to an official release (hopefully by > > Christmas)? > > I was just about to say something about this on the list, so I'll do it > in reply to your question: > > Yes, I'd like to get the CVS version finished up and a new release made. > I'm currently reviewing a few old emails I had marked, and checking in > some minor changes. > > Some questions for everyone: > > - What issues remain that need to be worked out before a new release? >For instance, we should probably organize a security audit of the >code changes for the new version (some auditing was done recently, >but I'm not sure exactly how much). > > - What should we call the new version? I'm leaning towards 2.6.0 >because of the new features (such as --files-from) and the various >large changes (such as better check-summing, fixed include/exclude >matching, etc.), but I could be talked into 2.5.8. > > If the remaining issues are small, I'll create a test release tarball in > the next day or so, which will allow those adverse to CVS to help out in > the pre-release testing. I'm leaning more towards 2.6.0 now given the number and scope of enhancements already in the code. The protocol bump doesn't merit a version bump (2.x.0) because it is strictly internal but the improved wildmatch, --files-from and better handling of large files together probably merit being called more than a "bug fix" release. The tool has been substantially improved in the last year and a bump will also draw attention to other substantive enhancements between 2.5.0 and 2.5.6 that people are not yet using. The new wildmatch stuff should probably get a mild caution in the release notes. I wish we had a better handle on the cygwin hang and craigb-perf but i don't want to slow things down. CVS is solid on *x now. The one thing i really would have liked to have seen in a version bump would have been changing the default remote shell to ssh instead of rsh/remsh. Both to discourage use of rsh and to eliminate the "rsh: access denied" or "rsh: command not found" errors that newbees keep hitting. Such a change needs the strong demarkation of a version bump. But i don't want to slow the release and there hasn't been any discussion on the subject since i suggested it. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Prepping for a new release (2.5.8? 2.6.0?)
On Mon, Dec 15, 2003 at 10:03:28AM -0800, jw schultz wrote: > The new wildmatch stuff should probably get a mild caution in the > release notes. Yes, it has the potential to trip up advanced users. I'm thinking about a short blurb that explains how to create exlude patterns that behave the same on both old and new versions (e.g. anchor all wildcard strings, make all '*'s "**"s if there is any "**" in the string, etc.). > I wish we had a better handle on the cygwin hang and craigb-perf but i > don't want to slow things down. It sounds like Cygwin might be fixing the cause of the hang on their end, so that's encouraging. I too would like to see the buffered output (craigb-perf patch) properly integrated, but have been wary of adding a new hang. We should probably apply it just after 2.6.0 and just work out any problems it might cause before the next release. > The one thing i really would have liked to have seen in a version bump > would have been changing the default remote shell to ssh instead of > rsh/remsh. I can see this being both a good thing (since I think it is a better default for new users) and a painful thing (for people who still use rsh). I'd be in favor of making this change, but I'm not sure if we should try to slip it into 2.6.0 or not; on the one hand it is a very simple change to make, but on the other it has a big impact on how rsync works. I suppose we should just leave it for later. I made one pass through the TODO and INSTALL files looking for outdated info. I'd appreciate some other eyes giving these a quick scan. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Prepping for a new release (2.5.8? 2.6.0?)
On Mon, Dec 15, 2003 at 10:51:08AM -0800, Wayne Davison wrote: > On Mon, Dec 15, 2003 at 10:03:28AM -0800, jw schultz wrote: > > I wish we had a better handle on the cygwin hang and craigb-perf but i > > don't want to slow things down. > > It sounds like Cygwin might be fixing the cause of the hang on their That is encouraging. My own suspicion is that the bug is at a lower level but if the Cygwin folk can fix it they'll deserve some kudos. > end, so that's encouraging. I too would like to see the buffered output > (craigb-perf patch) properly integrated, but have been wary of adding a > new hang. We should probably apply it just after 2.6.0 and just work > out any problems it might cause before the next release. My thoughts exactly. > > The one thing i really would have liked to have seen in a version bump > > would have been changing the default remote shell to ssh instead of > > rsh/remsh. > > I can see this being both a good thing (since I think it is a better > default for new users) and a painful thing (for people who still use > rsh). I'd be in favor of making this change, but I'm not sure if we > should try to slip it into 2.6.0 or not; on the one hand it is a very > simple change to make, but on the other it has a big impact on how rsync > works. I suppose we should just leave it for later. I only brought it up because i think the default --rsh should only change with a 2.x.0 release. That would mean change it now, do a 2.5.8, or wait to change it until 2.7.0 which could be years and i think it should be done sooner rather than later. I'll start a new thread for the technical details. > I made one pass through the TODO and INSTALL files looking for outdated > info. I'd appreciate some other eyes giving these a quick scan. I just did a pass on the TODO and it needs work. I spotted at least one duplicate. I'll look into reorganising it and assigning labels when missing to allow item discussion. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
default --rsh
On Mon, Dec 15, 2003 at 10:51:08AM -0800, Wayne Davison wrote: > On Mon, Dec 15, 2003 at 10:03:28AM -0800, jw schultz wrote: > > > The one thing i really would have liked to have seen in a version bump > > would have been changing the default remote shell to ssh instead of > > rsh/remsh. > > I can see this being both a good thing (since I think it is a better > default for new users) and a painful thing (for people who still use > rsh). I'd be in favor of making this change, but I'm not sure if we > should try to slip it into 2.6.0 or not; on the one hand it is a very > simple change to make, but on the other it has a big impact on how rsync > works. I suppose we should just leave it for later. Code-wise it is almost trivial but user impact for those that depend on the default being rsh or remsh is potentially non-trivial. I think most that need rsh instead of ssh would be fine just setting RSYNC_RSH but the magic with [non]blocking io based on if ((blocking_io == -1) && (strcmp(cmd, RSYNC_RSH) == 0)) blocking_io = 1; might means some might have to add the --blocking-io option so they might as well use "-e rsh --blocking-io". Of course that bit of logic also means that "configure --with-rsh=ssh" would get the logic wrong too so it is in a sense broken already. I suppose we could change that to if ((blocking_io == -1) && (strcmp(cmd, 'rsh') == 0) || (strcmp(cmd, 'remsh') == 0)) blocking_io = 1; Which comes close to the intent of the original though it doesn't deal with someone doing "configure --with-rsh=/usr/local/bin/rsh" It would be worthwhile to add a note in INSTALL to advise people of the --with-rsh configure option. Any thoughts, particularly with regard to putting this in before 2.6.0? -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Prepping for a new release (2.5.8? 2.6.0?)
On Mon, Dec 15, 2003 at 11:51:25AM -0800, jw schultz wrote: > On Mon, Dec 15, 2003 at 10:51:08AM -0800, Wayne Davison wrote: > > I made one pass through the TODO and INSTALL files looking for outdated > > info. I'd appreciate some other eyes giving these a quick scan. > > I just did a pass on the TODO and it needs work. I spotted > at least one duplicate. I'll look into reorganising it and > assigning labels when missing to allow item discussion. OK, first pass on TODO complete. I found a number of duplicate entries in the TODO list. Below is a revised file with a TOC at the top. I've attempted to attach dates to some of the entries based on the cvs log. I also retitled some of them to be more informative or to put them in the imperative sense. One i didn't know where to put is "hang/timeout friendliness" I don't even know what that means. Unless someone can clue me in i'll drop it. Please let me know if you would like different ordering or format of any of this. I have each item in a separate file with them in directories by section so reordering is easy at the moment. -*- indented-text -*- BUGS --- Fix hardlink reporting 2002/03/25 Fix progress indicator to not corrupt log lchmod question Do not rely on having a group called "nobody" Incorrect timestamps (Debian #100295) Win32 FEATURES server-imposed bandwidth limits rsyncd over ssh Use chroot only if supported Allow supplementary groups in rsyncd.conf 2002/04/09 Handling IPv6 on old machines Other IPv6 stuff: Add ACL support 2001/12/02 Lazy directory creation Conditional -z for old protocols proxy authentication2002/01/23 SOCKS 2002/01/23 FAT support Allow forcing arbitrary permissions 2002/03/12 --diff david.e.sewell 2002/03/15 Add daemon --no-detach and --no-fork options Create more granular verbosity jw 2003/05/15 DOCUMENTATION Update README Keep list of open issues and todos on the web site Update web site from CVS Perhaps redo manual as SGML LOGGING -- Make dry run list all updates 2002/04/03 Memory accounting Improve error messages Better statistics: Rasmus 2002/03/08 Perhaps flush stdout like syslog Log deamon sessions that just list modules Log child death on signal Keep stderr and stdout properly separated (Debian #23626) Log errors with function that reports process of origin verbose output David Stein 2001/12/20 Add reason for transfer to file logging debugging of daemon 2002/04/08 internationalization DEVELOPMENT Handling duplicate names Use generic zlib2002/02/25 TDB:2002/03/12 Splint 2002/03/12 Memory debugger Create release script Add machines to build farm PERFORMANCE -- File list structure in memory Traverse just one directory at a time Hard-link handling Allow skipping MD4 file_sum 2002/04/08 Accelerate MD4 String area code TESTING -- Torture test Cross-test versions 2001/08/22 Test on kernel source Test large files Create mutator program for testing Create configure option to enable dangerous tests If tests are skipped, say why. Test daemon feature to disallow particular options. Create pipe program for testing Create test makefile target for some tests Test "refuse options" works RELATED PROJECTS - rsyncsh http://rsync.samba.org/rsync-and-debian/ rsyncable gzip patch rsyncsplit as alternative to real integration with gzip? reverse rsync over HTTP Range BUGS --- Fix hardlink reporting 2002/03/25 (was: There seems to be a bug with hardlinks) mbp/2 build$ ls -l /tmp/a /tmp/b -i /tmp/a: total 32 2568307 -rw-rw-r--3 mbp mbp29 Mar 25 17:30 a1 2568307 -rw-rw-r--3 mbp mbp29 Mar 25 17:30 a2 2568307 -rw-rw-r--3 mbp mbp29 Mar 25 17:30 a3 2568310 -rw-rw-r--5 mbp mbp29
Re: default --rsh
On Mon, Dec 15, 2003 at 12:11:41PM -0800, jw schultz wrote:
> It would be worthwhile to add a note in INSTALL to advise people of
> the --with-rsh configure option.
I would not currently recommend that people use --with-rsh to set the
default to be ssh because that affects the blocking I/O default in a
weird way (i.e. it makes ssh default to blocking I/O and an override of
rsh default to non-blocking I/O, which is backwards from what is
desired).
> Any thoughts, particularly with regard to putting this in before
> 2.6.0?
I've attached one possible patch that does the following:
- Changed configure.in to set RSYNC_RSH to "ssh" by default (be sure to
run "autoconf" if you try this patch).
- Changed main.c to make blocking_io be the default if the remote shell
command is either rsh or remsh (instead of comparing with RSYNC_RSH).
We should then add a prominent release note that says that any site that
still desires a default of rsh (or remsh) should add "--with-rsh=rsh"
(or "--with-rsh=remsh") to their ./configure command.
I'm feeling a little more comfortable with this change now. What do
folks think about having something like this in 2.6.0?
..wayne..
--- configure.in15 Dec 2003 19:00:20 - 1.173
+++ configure.in16 Dec 2003 04:24:31 -
@@ -90,14 +90,14 @@
[ --with-included-poptuse bundled popt library, not from system])
AC_ARG_WITH(rsync-path,
- [ --with-rsync-path=PATH set default --rsync-path to PATH (default:
\"rsync\")],
+ [ --with-rsync-path=PATH set default --rsync-path to PATH (default: rsync)],
[ RSYNC_PATH="$with_rsync_path" ],
[ RSYNC_PATH="rsync" ])
AC_DEFINE_UNQUOTED(RSYNC_PATH, "$RSYNC_PATH", [location of rsync on remote machine])
AC_ARG_WITH(rsh,
- AC_HELP_STRING([--with-rsh=CMD], [set rsh command to CMD (default: \"remsh\"
or \"rsh\")]))
+ AC_HELP_STRING([--with-rsh=CMD], [set remote shell command to CMD (default:
ssh)]))
AC_CHECK_PROG(HAVE_REMSH, remsh, 1, 0)
AC_DEFINE_UNQUOTED(HAVE_REMSH, $HAVE_REMSH, [remote shell is remsh not rsh])
@@ -105,11 +105,8 @@
if test x"$with_rsh" != x
then
RSYNC_RSH="$with_rsh"
-elif test x"$HAVE_REMSH" = x1
-then
- RSYNC_RSH="remsh"
else
- RSYNC_RSH="rsh"
+ RSYNC_RSH="ssh"
fi
AC_DEFINE_UNQUOTED(RSYNC_RSH, "$RSYNC_RSH", [default -e command])
--- main.c 11 Sep 2003 04:53:05 - 1.172
+++ main.c 16 Dec 2003 04:24:31 -
@@ -241,8 +241,15 @@
args[argc++] = rsync_path;
- if ((blocking_io == -1) && (strcmp(cmd, RSYNC_RSH) == 0))
- blocking_io = 1;
+ if (blocking_io == -1) {
+ char *cp = strrchr(cmd, '/');
+ if (cp)
+ cp++;
+ else
+ cp = cmd;
+ if (strcmp(cp, "rsh") == 0 || strcmp(cp, "remsh") == 0)
+ blocking_io = 1;
+ }
server_options(args,&argc);
--- rsync.h 15 Dec 2003 08:07:38 - 1.157
+++ rsync.h 16 Dec 2003 04:24:31 -
@@ -107,9 +107,7 @@
#include "config.h"
-/* The default RSYNC_RSH is always set in config.h, either to "remsh",
- * "rsh", or otherwise something specified by the user. HAVE_REMSH
- * controls parameter munging for HP/UX, etc. */
+/* The default RSYNC_RSH is always set in config.h. */
#include
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: default --rsh
On Mon, Dec 15, 2003 at 08:29:36PM -0800, Wayne Davison wrote:
> On Mon, Dec 15, 2003 at 12:11:41PM -0800, jw schultz wrote:
> > It would be worthwhile to add a note in INSTALL to advise people of
> > the --with-rsh configure option.
>
> I would not currently recommend that people use --with-rsh to set the
> default to be ssh because that affects the blocking I/O default in a
> weird way (i.e. it makes ssh default to blocking I/O and an override of
> rsh default to non-blocking I/O, which is backwards from what is
> desired).
I intended my suggestion of the INSTALL note to be
conditional on the logic being changed.
Your patch looks like what i was suggesting with the
improvement to cope with "-e /path/to/rsh" very nice.
>
> > Any thoughts, particularly with regard to putting this in before
> > 2.6.0?
>
> I've attached one possible patch that does the following:
>
> - Changed configure.in to set RSYNC_RSH to "ssh" by default (be sure to
>run "autoconf" if you try this patch).
>
> - Changed main.c to make blocking_io be the default if the remote shell
>command is either rsh or remsh (instead of comparing with RSYNC_RSH).
>
> We should then add a prominent release note that says that any site that
> still desires a default of rsh (or remsh) should add "--with-rsh=rsh"
> (or "--with-rsh=remsh") to their ./configure command.
>
> I'm feeling a little more comfortable with this change now. What do
> folks think about having something like this in 2.6.0?
>
> ..wayne..
> --- configure.in 15 Dec 2003 19:00:20 - 1.173
> +++ configure.in 16 Dec 2003 04:24:31 -
> @@ -90,14 +90,14 @@
> [ --with-included-poptuse bundled popt library, not from system])
>
> AC_ARG_WITH(rsync-path,
> - [ --with-rsync-path=PATH set default --rsync-path to PATH (default:
> \"rsync\")],
> + [ --with-rsync-path=PATH set default --rsync-path to PATH (default: rsync)],
> [ RSYNC_PATH="$with_rsync_path" ],
> [ RSYNC_PATH="rsync" ])
>
> AC_DEFINE_UNQUOTED(RSYNC_PATH, "$RSYNC_PATH", [location of rsync on remote machine])
>
> AC_ARG_WITH(rsh,
> - AC_HELP_STRING([--with-rsh=CMD], [set rsh command to CMD (default: \"remsh\"
> or \"rsh\")]))
> + AC_HELP_STRING([--with-rsh=CMD], [set remote shell command to CMD (default:
> ssh)]))
>
> AC_CHECK_PROG(HAVE_REMSH, remsh, 1, 0)
> AC_DEFINE_UNQUOTED(HAVE_REMSH, $HAVE_REMSH, [remote shell is remsh not rsh])
> @@ -105,11 +105,8 @@
> if test x"$with_rsh" != x
> then
> RSYNC_RSH="$with_rsh"
> -elif test x"$HAVE_REMSH" = x1
> -then
> - RSYNC_RSH="remsh"
> else
> - RSYNC_RSH="rsh"
> + RSYNC_RSH="ssh"
> fi
>
> AC_DEFINE_UNQUOTED(RSYNC_RSH, "$RSYNC_RSH", [default -e command])
> --- main.c11 Sep 2003 04:53:05 - 1.172
> +++ main.c16 Dec 2003 04:24:31 -
> @@ -241,8 +241,15 @@
>
> args[argc++] = rsync_path;
>
> - if ((blocking_io == -1) && (strcmp(cmd, RSYNC_RSH) == 0))
> - blocking_io = 1;
> + if (blocking_io == -1) {
> + char *cp = strrchr(cmd, '/');
> + if (cp)
> + cp++;
> + else
> + cp = cmd;
> + if (strcmp(cp, "rsh") == 0 || strcmp(cp, "remsh") == 0)
> + blocking_io = 1;
> + }
>
> server_options(args,&argc);
>
> --- rsync.h 15 Dec 2003 08:07:38 - 1.157
> +++ rsync.h 16 Dec 2003 04:24:31 -
> @@ -107,9 +107,7 @@
>
> #include "config.h"
>
> -/* The default RSYNC_RSH is always set in config.h, either to "remsh",
> - * "rsh", or otherwise something specified by the user. HAVE_REMSH
> - * controls parameter munging for HP/UX, etc. */
> +/* The default RSYNC_RSH is always set in config.h. */
>
> #include
>
> --
> To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--
J.W. SchultzPegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: default --rsh
> I'm feeling a little more comfortable with this change now. What do > folks think about having something like [ssh instead of rsh as default] in 2.6.0? I'd say go for it. If nothing else, it would be nice to get away from the current situation of potentially *encouraging* newbs to *start* using rsh because it's rsync's default behavior. Sort of an "if you don't know how to enable rsh then you shouldn't *be* enabling rsh" situation, if you know what I mean. Besides, I'm personally at a loss to understand why anybody would (much less should) still be using rsh in the first place. If they're running rsync on an incredibly old machine and want to conserve the cycles ssh would use for encryption or don't have ssh available, they can always just run an rsync daemon. -Jim Salter -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
