On Fri, Jun 22, 2001 at 05:26:52PM -0700, Wayne Davison wrote:
> On Fri, 22 Jun 2001, Dave Dykstra wrote:
> > > The default value of the non-blocking IO is not
> > > affected by this change -- instead rsync only sets non-blocking IO by
> > > default if the RSYNC_RSH value is "rsh" or (if remsh is around) "remsh".
> >
> > This is a very tricky thing to do right, and probably the main reason why
> > Martin gave up on doing it. Your patch doesn't do it right (see below).
>
> The current code is also broken, and I didn't want to try to solve the
> deeper problem in a patch that was just attempting to add a configure
> option. I think my patch is just slightly less broken in this area than
> what is currently in cvs, but not by much (since the man page says that
> rsh defaults to blocking IO, but the current code will not default to
> blocking IO with "-e rsh" if remsh is the default remote shell). I
> specifically left off any path-based matching so that people could
> specify an rsh without blocking IO.
Yes, I see what you mean and now I think your way is better.
> I think a better method would be for rsync to have a default blocking
> setting for the default remote shell (perhaps configurable along with
> what the remote shell is), and then let the user override the proper
> remote shell and blocking behavior for their transport.
How is that different from the way it is now?
> The biggest
> complicating factor with this is the RSYNC_RSH environment variable,
> since there is no way to specify the blocking mode associated with this
> value. For instance, if some sysadmin were to globally set RSYNC_RSH to
> "/foo/rsh" and it needed to use blocking IO, all users would be required
> to manually specify the --blocking-io option.
>
> Perhaps we need some kind of a config file setup like ssh uses? It
> would be possible to specify a different shell/blocking combination as
> the default, perhaps even based on hostname matching (again, like ssh
> supports), and the user could specify their own overrides, as needed.
> This would allow things like using rsh for local systems, and ssh for
> remote ones.
Perhaps a ~/.rsync or ~/.rsync/config and /etc/rsync.conf like ssh will be
useful someday to specify any default option, even host-based, but I
wouldn't do it because of this issue because I don't think it will help
much with solving the problem of selecting the right blocking-io setting.
> > I don't think it's a good idea to change the default, because of the
> > surprise factor as you change from machine to machine and because
> > there are a number of significant differences between rsh and ssh.
>
> For me I don't even have rsh installed at home, and it is disabled at
> work, so an rsync that doesn't function (because it defaults to using
> rsh) is a bigger surprise factor for a novice user. I edited the source
> to use ssh as the default when I installed it at work, and will continue
> to do this if rsync doesn't support a configure option in the future.
Good point.
I now think your patch should be accepted, but it will be up to Martin or
Tridge to put it in.
- Dave
